What I learned from reviewing 50 competitor blogs
I spent two weeks reading every blog post from Appcues, Userpilot, Pendo, WalkMe, Whatfix, UserGuiding, Chameleon, ProductFruits, HowdyGo, and a dozen smaller onboarding tools. Fifty blogs. Hundreds of articles. I was building Tour Kit, a headless product tour library for React, and I wanted to understand the content space before writing a single post.
What I found was surprising. Not because the content was bad (some of it is genuinely useful), but because every single vendor follows the same playbook. And that playbook has a blind spot the size of a continent.
Every vendor runs the same playbook
The first thing that hits you when you read 50 SaaS onboarding blogs back-to-back is the sameness. Every vendor publishes the same four content types: comparison pages where they position themselves as the winner, "best tools" listicles where they rank themselves first, feature guides that funnel into demos, and template content designed to capture high-intent search traffic.
Userpilot publishes "Appcues vs Pendo: An Honest Comparison + A Better Alternative" where the "better alternative" is always themselves. Appcues does the same with "5 Best Userpilot Alternatives." Everyone claims to be honest. Nobody is.
I counted the comparison articles across the top 10 vendors. Between them, they've published over 200 "X vs Y" posts. A single search for "appcues vs pendo" returns at least six competing vendor blog posts, each spinning the comparison in their own direction.
As of April 2026, 31% of content marketers budget between $15,000 and $45,000 per month on content production, up from 19% in 2025 (Siege Media). That money is producing a lot of content. But when you read it all at once, the duplication is staggering.
Nobody writes for the people who actually build the tours
This was the biggest finding. Every competitor blog targets product managers, UX designers, and marketing teams. The writing style is accessible, metaphor-heavy, and deliberately non-technical. Appcues uses a "conversational, relatable approach" with phrases like "Swiss army knife" to describe their platform.
But somebody has to implement the tour. Somebody writes the code, debugs the positioning logic, handles the z-index conflicts, figures out why the tooltip disappears on scroll. That person is a developer. No onboarding vendor writes for them.
I searched every blog for code examples. Real code, not screenshots of a drag-and-drop builder. Almost nothing. Documentation exists, siloed away from the blog. The blog handles "thought leadership" and lead generation. The docs serve people who already bought the product.
DigitalOcean figured this out years ago. They have 8,000+ developer tutorials and a Write for DOnations program that pays community authors to create educational content. It's the polar opposite of what onboarding vendors do, and it works dramatically better for building developer trust.
This gap is why Tour Kit's blog exists. We write for the developer who's going to npm install something and wire it up on a Tuesday afternoon. Not the PM who needs a slide deck about onboarding metrics.
The recycled examples problem
Every onboarding blog references the same five companies: Slack, Shopify, Asana, Notion, and sometimes Figma. I read "15 Product Tour Examples" from three different vendors and the overlap was about 70%.
The reason is obvious. These companies have well-known onboarding flows, they're safe to reference, and the screenshots are easy to capture. But it creates a weird echo chamber where every blog post feels like it's describing the same product.
Samuel Hulick's UserOnboard site stands out precisely because it doesn't follow this pattern. Hulick built an entire audience through templated teardowns of onboarding flows -- 60+ screenshots per teardown, walking through the experience step by step. As Animalz noted, this format creates "predictability and surprise" that keeps readers coming back.
Nobody in the product tour vendor space has adopted this approach. They reference UserOnboard's teardowns in their own blog posts, but they don't do teardowns themselves. It's a format that works, and it's sitting right there, unclaimed.
What went wrong: the AI content flood
I could tell which articles were written by humans and which were generated by AI. The AI ones have a particular rhythm: perfectly parallel paragraphs, synonym cycling instead of repeating product names, and that distinctive "In today's rapidly evolving..." throat-clearing.
The numbers back this up. As of 2026, 85% of tech marketers use AI beyond exploratory stages, according to Content Marketing Institute research. But usage for drafting fell from 57% to 44% between 2025 and 2026. Brainstorming and outlining dropped from 72% to 61%.
The industry is course-correcting. One CMI panelist put it bluntly: "One of the great ironies of this AI craze is how much it makes people value interactions with real people." Backlinko's 2026 trends report went further: "Thought leadership now requires original insight. Repackaging what already ranks won't build authority; bold takes, experienced authors, and first-party data will."
Reading 50 blogs in two weeks gave me a visceral sense of what AI-generated content looks like at scale. It's not that any single post is terrible. It's that they all sound the same. And when everything sounds the same, nothing stands out.
Key decisions: choosing honesty over conversion
Here's a pattern I didn't expect. Most vendor blogs spend more energy attacking competitors than explaining their own product. Userpilot has more articles about Appcues than about its own features. Appcues writes more about Pendo's limitations than about what makes Appcues good.
This creates a race to the bottom. Vendor publishes aggressive comparison. Competitor responds with their own. More comparisons follow. The reader ends up with a dozen biased perspectives and zero useful information.
The fix isn't complicated. State your bias. Acknowledge what competitors do well. Give the reader enough information to make their own decision. I wrote about this in our Tour Kit vs React Joyride comparison -- we acknowledge that React Joyride has 603K weekly downloads and is battle-tested, while Tour Kit is younger and has a smaller community.
Does that honesty cost us some conversions? Probably. But developers can smell marketing from three paragraphs away. And promotional language actually reduces AI engine citations by 26%, according to Semrush research. Being honest is both the right thing to do and the better strategy.
What worked: three changes to Tour Kit's content
After reading 50 competitor blogs, I changed three things about Tour Kit's content approach.
First, every article starts with code. Not a header image. Not a "what is product tours" definition. Code. If someone lands on a Tour Kit blog post, they should see a working example within the first scroll.
Second, I stopped writing comparison articles where Tour Kit magically wins every category. We're an 8KB headless library built by a solo developer. We don't have a visual builder. We don't support mobile. React 18+ only. Those are real limitations, and pretending otherwise insults the reader.
Third, I started publishing data that no vendor blog provides. Bundle size comparisons with actual gzipped numbers from bundlephobia. Lighthouse accessibility scores. Core Web Vitals impact measurements. First-party performance data is the one thing AI can't generate and competitors won't share.
What I'd do differently
If I were starting this competitor blog analysis over, I'd track three things more carefully.
Publishing cadence. Some vendors post daily, others weekly. I didn't record exact dates, and that data would have been useful for understanding content velocity. 76.4% of ChatGPT's most-cited pages were updated within the last 30 days, so freshness matters more than volume.
CTA placement and density. Appcues puts free demo CTAs at least three times per article. Others are more restrained. I noticed the pattern but didn't measure it systematically.
And I'd have built a simple database instead of a spreadsheet. Tracking 50 blogs across a dozen dimensions in Google Sheets was painful by the third day.
What's next
I'm planning code-forward teardowns -- the same concept as UserOnboard, but from a developer's perspective. Not just "here's what the onboarding looks like" but "here's what's happening in the DOM, here's the bundle cost, here's the accessibility audit."
Nobody does this. And as Smashing Magazine pointed out years ago, "content marketing needs to offer practical advice that people can use." Screenshots of pretty tooltips aren't practical advice for the developer who has to build the tooltip.
The onboarding content space is crowded but narrow. Everyone writes the same articles for the same audience using the same format. The gap isn't in what's being published. It's in who it's being published for.
If you're a developer evaluating product tour options, check out Tour Kit's documentation. It's written for you. Not your PM.
Internal linking suggestions:
- Link from Tour Kit vs React Joyride → this article (in context of honest comparisons)
- Link from Best free product tour libraries → this article (in context of how vendors bias their comparisons)
- Link from Composable tour library architecture → this article (in context of developer-first content)
Distribution checklist:
- Hacker News (Show HN angle: "I read 50 SaaS competitor blogs so you don't have to")
- Reddit r/SaaS, r/startups, r/content_marketing
- Indie Hackers (building in public angle)
- Dev.to cross-post with canonical URL
- LinkedIn native article
Related articles
How AI will change product onboarding (and what won't change)
AI will personalize onboarding timing, content, and sequencing. But trust, accessibility, and user control still require human decisions. A developer's take.
Read article
Why the best onboarding software in 2026 is a React library
Code-first React libraries beat SaaS onboarding platforms on cost, performance, and control. Pricing data, bundle sizes, and architecture compared.
Read article
GitHub stars don't pay the bills (but they help)
A solo developer's honest look at what GitHub stars actually do for an open-source library. Real numbers on the gap between stars and revenue.
Read article
From 0 to 1000 GitHub stars: the Tour Kit playbook
How I grew a React product tour library from zero to its first 1,000 GitHub stars as a solo developer. Real tactics, real numbers, no paid ads.
Read article