How to create a good dev tool comparison page

You vs competitor comparison pages. For some reason, this is a controversial subject. In dev tools especially. Here is my "controversial" opinion: 

You vs Competitor comparison pages are valuable. Both for you and your users.

‍Dev users and prospects ask about them all the time. And you can make people schedule a demo with you to ask “how are you different than …” or let developers self-serve that answer. If you are in dev tools you know very well that low-friction self-served is generally the way to go. 

But creating a good dev tool vs competitor comparison seems hard. For a few days, I looked around dev tool vs pages. Found many “not-so-great” examples and a few really good ones. So yeah, while it doesn’t seem easy to crash it, you certainly can. Let’s focus on the how. 

In this article, I go deep into how to do just that. Namely:

• Why create comparison pages (and when you shouldn’t)
• What makes a good comparison page
• My baseline for you vs competitor page
• Examples of dev tool comparison pages

Let’s get to it. 

Why create comparison pages (and when you shouldn’t)

I always try to come from the “is this helpful to users” standpoint. And if I have evidence that something is helpful to your dev audience, I suggest you consider creating it. 

But how do you know?

Well, here are some tips:

• you are at a conference and 2 minutes into every other conversion, you get asked “ok, I get it, so how are you different than X”. 
• your devs/devrels find it easiest to explain to people that you are “just like X but with Y, and we think about Z differently”.
• you literally built your product to be a replacement for a well-known commercial or open-source incumbent. 

Those are typically good signs that you should address the “how are you different” question. 

And if you believe in truly self-serving your developer audience (and I certainly do), you just give it to them. No forms, no sales calls needed.

Besides, people will ask anyway. They will go to Reddit, Hacker News, or Google and type. They will read people’s opinions, and make up their minds. They will happily see how you think you are different too. And if you can make your point in a way that is valuable to that developer you can score some points here. You can also let a dev, who had a horrible experience with your product 3 years ago, be the loudest voice in the room.   

On top of that, there are clear business benefits. Showing up when people are in the evaluation/consideration mode and googling “Big competitor vs”, being able to link to this from everywhere, and aligning the team internally on your differentiators are just good business. 

Also, this is a good litmus test for whether you nailed that us vs them narrative. If your sales or product team would never send people to your comparison page, but instead they would write an ad-hoc comparison themselves, it is a good sign that the page is not good enough. Typically, it also means that your underlying understanding of the difference is not good enough either. And if it isn’t good enough for them it sure as hell is not good enough for your audience.

“But isn’t talking about competitors just wrong? Isn’t it doing marketing for them? Isn’t it sleazy and aggressive? Isn’t competition just a losing game?”

Again, I am trying to help the buyer/user choose. I am assuming they will do their due diligence anyway. I am anchoring on things they know. Don’t get me wrong, doing it well is hard, especially when you don’t really know how you are different. But you should know. And you should help your dev audience understand that. 

Now there are situations when you probably shouldn’t do a comparison page. For me, the biggest reason is some flavor of the following.  You are the incumbent, your name is associated with a category, say Datadog & Observability, and you are thinking about comparing yourself to a small startup that nobody is asking about. This will only help the startup. 

Ok, let’s get to it then. 

What makes a good comparison page

A good vs page is helpful, objective, and trustworthy:

• Helpful: It helps them understand how you are different, why you exist, why people choose you vs others, what are the use cases where you shine. It helps them decide if you are a good fit. 
• Trustworthy: To do that you should use third-party validation like user/customer testimonials, G2 reviews, performance benchmarks etc. 
• Objective: You choose comparison dimensions to match user needs, not your goals. You explain and show when a competitor is a better choice. 

While seems easy it is hard, especially for founders who are so emotionally attached to the product that they don’t see the reality. Ultimately, you don’t want to be a Frog Watch meme:

How do you do that though?

Get your data from real users of your and your competitor’s product. Ideally, including those who switched from competitor to you. My framework is to:

• Talk to your sales/cs/product/devrels
• Look at the testimonials/sales conversations you had. 
• Go to Reddit, Hacker News, G2 reviews, Trust Radius reviews. 
• See what people are saying.  
• Collate the insights into themes. 
• Communicate things using the words people from outside of your company are using (Voice of Customer data)
• Build a vs page
• Put it in front of your audience
• Listen and iterate on the feedback 

And the more folks you see converting through that page the more insights you will get. 

One more thing. Be gentle to your competitor ;).

I remember we ran a bunch of user testing interviews on one of our vs pages. Turned out that while people believed what we said was true they felt bad about the negative/aggressive tone of some of the copy we used. We tweaked the copy to focus on our benefits only and let the dev testimonials share those negative experiences. The results followed. 

But what does a good dev tool comparison page actually look like?

My baseline for you vs competitor pages

I’ll go into dev tool examples in the next section, but first wanted to share my baseline approach to this. 

So I suggest you tick the following boxes:

• Say when the competitor is good and show (hopefully) genuine respect for what they built.
• Hint at what you do better or how you are different. Typically you can find 1-3 core themes that really matter to folks who choose you.
• Present those core themes in more detail. Include the user/customer testimonial, third-party review/score, or benchmark to support your claims.
• Show a deeper capability-by-capability comparison. Go as deep as you think adds value to the audience but not deeper. Link to sources. Make sure to include things that you don’t have (remember, don’t be a Frog Watch). 

There are many ways of ticking these boxes. You can do a landing page or blog post. You can lean heavily on G2 or focus on the comparison table. You can write and publish it in-house or have someone write it for Medium. All have pros and cons.

I like the following as my baseline approach:

It is just a basic implementation of those points from above. But it works. 

Let’s now go over examples of how dev tool companies actually do it in real life. 

Examples of dev tool comparison pages

I divide examples by those components I mentioned in the previous section. 

But here is a list of my favorite dev tool comparisons that do one or many of those things well:

• Convex vs. Firebase
• Remix vs Next.js
• ClickHouse and Redshift
• Comparison to alternatives — Meilisearch documentation
• Ably vs Pusher
• Bruno Vs Postman
• (Old) New Relic vs Datadog 
• Contentful vs Strapi
• CockroachDB vs PostgreSQL
• V7 vs Labelbox

Starting with good things about the competitor

What we want to do in this section is “pay our respects” which among other things makes us seem more objective and hint at the fact that we are different. 

Convex does it well. They acknowledge that Firebase was the first team to solve this problem but there are things they see differently. I like how they give me three core differentiating themes. 

I think this is fairly objective as I saw the promoted this post on Twitter tagging Firebase

Remix goes even further. Their founder starts by calling folks from Vercel friends and asking their users not to be aggressive/divisive on socials about this. 

They double down on a few sections below:

Notice that these examples are coming from blog posts. It is easier to put more context/words in a blog post and make it more friendly/human. Landing pages are harder for that but you can still do it. 

Here is a great example of adding it even in a comparison video comes from CockraochDB:

Focus on 1-3 core differentiation themes and make sure they land

You want to first highlight those core differentiators and then prove them. Typically you’d do that with some clear messaging in the header/intro followed by sections with objective/trustworthy proof points. 

In the proof point sections, you want to pick only a few to give yourself enough room to explain them in enough detail to land. You can use technical jargon, screenshots/gifs from the product, SDKs, testimonials from devs, performance benchmarks depending on what you want to convey. 

I like how Convex does it. They start with three bullet points and then they go deeper on each bullet. And they explain it deeply with links to sources. 

Folks from Bruno explain their differences vs Postman well too. They go from the most important to the least one. The language is clear and concise. As they have 9 differences so I’d prefer to show it in a table (and I’d probably choose 1-3 that are the core). But their all-text approach gives it a more non-commercial feel which has benefits with the dev audience. 

Funny enough David Coomber, who is not associated with Bruno, managed to put a Bruno vs Postman comparison on the Postman domain. So it almost seems as if it was Postman who published it. That would have been a nice growth hack if it was done by Bruno ;)

Sometimes your product just wins on price. I like how New Relic owns it on their old vs Datadog page:

• They show you price comparison graphs
• The CTAs are focused on helping you compare the prices
• They use jargon specific to the category to drive the price argument: "peak usage", "overages and penalties", "SKUs"

After reading this I'd trust them to give me a solid price estimate and that it will likely be cheaper than Datadog. Obviously, price is not the only reason why we choose tools, but if that was a problem I had with Datadog, they have my attention.

If you are open-source then being self-hosted or simply being open-source is often a core part of the story you want people to remember. Strapi focuses on that benefit right in the header. 

And then they go deeper in the very first section.

I’d make that page header feel more like a dev tool and not a marketing tool but other than that the story lands. 

For CockroachDB, the big incumbent they are replacing is an open-source relational database default, PostgreSQL. And they explain very quickly why they exist. They spell out why you should care enough to consider it: you need an extra resilient, very scalable, and multi-region distributed database. 

In that video that I already shared, they drove those very same points. Really good work imho. 

Another database, ClickHouse is super scalable and cost-efficient as you scale it. They focus on those differences vs Redshift. 

I’d probably add a link to the performance benchmark they ran to make it more objective/believable. But ok, there are other ways of driving that trust.

Making it trustworthy and objective

In that vs page example above, Clickhouse put a video of a CTO explaining how they migrated off of Redshit. They also extracted a short testimonial from that video that drives the cost-efficiency benefit home. 

And then there are three more themes, each explained in detail and supported by a developer or CTO testimonial. All technical and trustworthy. Just a job well done. 

Another way of going for objective and trustworthy is third-party validation. Someone saying you are better is always stronger than you saying that about yourself. V7 goes all-in on G2 ratings. One nitpick here, I believe they lose some credibility by making equal scores show in different colors (green for V7, grey for Labelbox). This is a flavor of the Frog Watch problem that I believe every developer-facing product should avoid like wildfire. 

Now, what is the most reliable/trustworthy part of the dev tool website? Documentation. Meilsearch uses that, coupled with “issue pull request if anything is off” to drive the objective nature of their comparison home. After all if people (including the competitors mentioned) see problems with it they are happy to fix them.

Another classic approach is to just use testimonials. They can be super powerful, especially if you make sure they come from devs and talk about the differences vs the competitor. Strapi did just that. Bonus points for showing a wall-of-love style of Tweets. Ads a ton of credibility when devs talk about switching from the competitor on socials. 

If you want to drive a point about your tool being faster/more scalable the easiest way is to show benchmarks. Remix does just that here, they also use disarming dev-to-dev conversational copy coming straight from the founder. 

Giving people a deep comparison table

Devs love tables for comparing things. Now that I think about it who doesn’t? 

What you want to show in this section, is that you’ve done your homework. You want to give people details. The more detailed you go, the harder it will be to maintain but it will give more value to the reader and will make the entire page more believable. This is a tricky balance. 

I really like how ably approached their vs Pusher comparison by showing three rows: them, competitor, and why it matters. By doing that they not only show the difference but also explain the relevance of it for a particular set of use cases or situations. They back it up with links to docs. 

Cockroach goes for simplicity. They choose the most important themes and puts them in a table. Even though this is obviously not a complete list it gives this feel of thoroughness.

They choose to explain only the points where they are stronger and where those strengths are important. This could be good as you are showing the important diff. But you risk becoming a Frog Watch meme. Proceed with caution. 

But tables are not everything. There are sometimes design or philosophical differences. I like how Meilisearch gives people the option to either explore tables or read about different approaches those different tools are taking. There are multiple tables for features, deployment, community, and support, And they don’t win in every category which makes the whole narrative more objective and believable. 

What is next

Nice, hopefully now you know what to do:

• Do research (internal and external) to understand what those core differences are.
• Take that baseline I shared for a solid starting point and tweak it to land your differentiating story.
• Use examples I shared for inspiration as to how to drive each part of the message home (you can always find more vs page examples here)
• And then see if your sales/devrel/product team wants to share this page, if not put more work into it.

Remember that first and foremost this page should be helpful to your dev audience and potential users/prospects. And that there should be objective reasons, use cases, and situations when using your product is clearly and objectively the smart thing to do. 

After all, you do have happy users/customers who chose you over other products. Tell that story. 

If you need help with this, let me know. I really like working on this stuff.