Sometimes your pricing is just complex. But you can still make it work.
If you want devs to convert, make it possible for them to estimate the cost.
@Mux does it nicely with a calculator:
What is crucial is that the calculator dimensions need to be understandable and familiar to the reader.:
The goal of this is to make it possible for a person to get an estimate right here right now.
Not have to setup a meeting with half the team to figure your pricing out.
Super short dev tool case study on a single viewport.
Many case studies follow a Hero -> Problem -> Solution -> Results framework.
Many try and do it on a one-pager.
But what @Resend did is next level and I like it.
Especially with devs, you want to be technical and succinct.
And Resend took all the possible fluff out of it.
I'd like to have some before or after probably or a stronger results (or pain) ) focused headline.
But I think this is great actually.
This body cross-section is just awesome.
It makes it obvious that I can connect it to my workflow.
This is a must for dev-focused pages imho.
What I like:
- there are many integrations listed
- I can see the code and that it is easy to use
- The CTA is to integration docs, awesome!
There are three CTAs actually.
Common knowledge suggests doing one, maybe two, they do 3:
Devs want relevant and practical.
Also, devs love docs and examples and check them before signing up.
Action-focused copy is great as well.
That CTA.
You go straight for the install/download.
I don't know if you can go more developer-focused than that.
It sets the tone for the entire homepage.
And let's be honest (almost) nobody actually clicks that "Sign up" button in the hero section.
Your dev tool is faster/more scalable/more X -> show it with benchmarks.
For some tools the entire unique selling point is that they are faster.
You build your messaging around that, put a flavor of "fastest Y for X" in the header and call it a day.
But devs who come to your website cannot just take your word for it. They need to see it, test it.
For some tools it is possible to just see it for themselves, get started.
But you cannot expect devs to really take a database or an observability platform for a spin.
As to test the speed or scalability on realistic use case you need to...
... set up a realistic use case. Which takes a lot of time.
But you can set that use case and test it for them. With benchmarks.
I really like how Astro approached it:
If your usp is that you are faster/more scalable/ more whatever. Back it up. This is the nr 1 thing devs on your website need to trust you with to move forward.
I like how it has a proper "hero section" feel to it but it adds a developer-focused twist:
The rest of the Readme is great as well but the hero section is gold imho.
There are many things that I like about it.
Overall with very little effort, I understand what it is, and what it does.
And I can go and dig deeper for myself or spread the word with my circles.
I love this copy. It answers:
It doesn't talk about the value as it is obvious to devs.
Obviously, it will save time and make things safer.
Don't talk about it.
I like the design of this crosshead.
I like this idea of showing how your dev tool works.
With developers, you almost have to explain how it works on your homepage.
Many products do some version of Step 1 -> Step 2 -> Step 3 -> Success.
I really like how @SST approached it with a timeline.
I find it more engaging than those disconnected steps.
And when I follow this journey the final and logical step is to try it out. Get started.
Why not highlight your free plan?
Most companies highlight their middle paid plan saying it is "most popular".
First thing, yeah, sure it is your most popular plan.
But more importantly, most visitors will not convert to your paid plans right away.
So why not try and capture as many devs as possible on the free plan?
If they like your dev tool there are many things you can do to convert some of them to paid plans.
But if they leave that pricing page and go with some other free tool, you are not converting anyone.
@CircleCI highlights free and they are in the mature, competitive market of CI CD tools.
Idk, it really does make a lot of sense to me.
If people need more advanced features they will choose higher plans anyway.
But if they want to get things started with the basic plans they will choose free or go elsewhere.
I'd rather have them choose free than none.
When selling dev tools you typically have 3 "buyer" levels:
Individual dev:
Team lead:
Org lead:
How does Postman solve it?:
They even go the extra mile. Something I didn't see too often.
They understand their customer's reality and identified one more level between Org and Team.
Basically a department-level unit that probably has multiple teams but is not at the organization/enterprise level.
I really like what they did hear. Solid.
Most dev tools have two deployment options:
And then companies present it on their pricing page with some flavor of two tabs.
And you need to name them somehow.
And how you describe those things sometimes adds confusion for your buyers:
I like how nice and simple solution Retool used on their pricing page:
Explicit, obvious and to the point.
Love it.
I like that this is both strong and subtle.
It comes right after I've delivered a smell of value with a technical intro.
And I can see that there is more value to come after thanks to the table of contents.
The CTA itself feels like an info box in the docs rather than a typical subscribe CTA.
Good stuff.
Looking for a good dev-focused case study format?
People tell you to follow a classic Hero > Problem > Solution > Results.
They tell you to show numbers, talk value, etc.
And it is true. Great format.
But packaging this for devs is hard.
For example, putting numbers in there, and framing it in a "save 28min every week" is a recipe for losing trust with that dev reader.
That is if you can even get those numbers from your customers.
I like how @LaunchDarkly solves it.
Hero section:
Case study body:
They keep the content down to earth and devy but still frame it in a value-focused way.
I like that that they speak in the currency that devs care about.
Wasted time.
Before: "Took 2-3 weeks to ship"
After: "Can ship experiments every day"
The cool thing is you could actually use this hero section format and then have a more technical user story below. By doing that you could speak to the why and how.
That depends on your target reader for this page of course.
Anyhow, I do like this format and I am planning to take it for a spin.
Pushing cold blog readers to try your tool rarely works.
So you need a transitional CTA, something that worms them up.
But it needs to be aligned with the goals of the reader.
And I think pushing folks to a community discord is a solid option.
I like the copy "Discuss this blog on Discord" as it is very reader-focused.
Some folks read the article and have more questions.
They want to discuss it somewhere.
And while you could just do a comments section, a community gives you more options to get people closer to the product.
Devs are builders.
Make your home page for builders.
Go directly into the "how" instead of the way.
Many devs when they land on your home page, already know the "why".
I love that it:
Understand who is reading. Add social proof that speaks to them.
Social proof is about showing people/companies who are similar to the reader that they got success with the tool.
Company logos can be good if your reader knows and likes those companies.
But if those are random companies, I am not sure how much value does it bring.
Devs care what other devs who use your product have to say about it.
That's why I like testimonials.
Not the crafted, clean ones with features and values.
But the real stuff. Real devs sharing real stories.
Bonus points for "Okay, I get the point" button copy.
It changes from "Show more" when you click.
Nice!
How to get people to sign up for your office hours?
Why not put it on your docs homepage?
Btw, I really like the concept of office hours.
You get your devrels or product to do those weekly and then you just have to figure out how to get people there.
Classic options are to put info in onboarding sequences, in the app, or on the website hello bar.
But Flatfile had another idea. They put it in their docs homepage header.
I find this idea brilliant as many people who browse your docs (especially for the first time) are in that evaluation mode and would actually want to do that.
Plus calls to action in the docs get more respect by design ;)
I really love this hand-drawn feel.
It makes it super authentic.
Also, starting from scratch (not a ready diagram) makes following it more fun and less overwhelming.
Great stuff.
BTW the tool used for this is called excalidraw.com
Many dev tools have complex pricing and packaging.
Say your dev tool/platform has many product offerings.
And you offer usage-based pricing but also enterprise plans but also per-product options, and additional customizations.
But you want to present it in a way that is manageable for the developer reading your pricing page.
Mux solves it this way:
Extended headers on pricing pages are not common as they add friction.
But sometimes adding friction is exactly what you need to do.
Mux managed to make this page (and their offering) easy to navigate by adding a little bit of friction at the beginning.
Maybe you don't browse plans right away but at least you don't waste energy (and attention) on the parts of the page that doesn't matter to you.
Good stuff.
Great above the fold
The subheader explains the value proposition.
Header handles major objections:
Then we have 3 CTAs but they are super focused on devs:
Then it goes on to explain how it works with a simple, static graphic.
This whole thing makes me feel peaceful.
The "Resources" tab is the most loved and hated tab for developer marketers.
Ok so the common problem is that you have lots of different resources:
You want to showcase them in the navbar but where do you put them?
Under product? Company? Docs?
How to make sure that people don't go to your blog to read about your product just to find out that you talk about the industry problems there?
Enter the "Resources" tab. The "Miscellaneous" of the navbar world.
And typically it is just crammed with all stuff that doesn't fit anywhere. Just like any respectable misc folder would.
How do you deal with that?
Snyk approached it in a clear and logical way:
I love this (and already stole the idea for our site).
Show how product components fit together.
A good diagram is such a good solution to that.
They use the same colors and eyebrow copy that was used for body sections.
It all clicks now, I get the full picture.
I love this simple design.
They show:
Simple, and powerful imho.
A docs header worth a thousand words.
For a dev platform or infrastructure tool it is hard to explain where you fit, what you do quickly, and how you connect to existing components quickly.
Hopsworks docs team does a great job here.
So instead of using words, they use a diagram:
All of that in a single diagram.
Now that is a dev-focused header visual.
In a mature category, it is safe to assume that people know about other tools.
Especially devs.
I love how Axiom owns its unique selling point and how it stands out from the competition.
Takes guts but I love it.
There are a lot of boring vendor t-shirts at conferences.
And they get boring results.
I like this bold design from GitGuardian:
Nice.
A great example of a dev-focused Linkedin post format from Khuyen Tran 👇
What I like about this:
Just great job!
Good in-place code pattern.
I can go and see different code snippets without moving to other parts of the website.
At the same time, I can read explanations and value propositions.
I like how "view documentation" is such a strong CTA with so much going on here already.
I love that it is static and it blurs everything I don't need to get the concept.
For the dev audience, static graphics, when done well, are better than
Tell me what you do in 1 sec, not 60
This is a simple but great header imho:
Love it.
How to design the navbar product tab? This is what @PostHog does 👇
Figuring out what to put in the navbar is tricky:
The "Product" tab is especially tricky.
It can get overloaded with a ton of content.
I like how Posthog approached it:
I like it.
Pricing in your docs? That is how @Fly.io does it.
You click a pricing page link on their homepage and you go to the docs!
No 3 boxes with the "most popular" being the middle paid plan ;)
They just give it to you how it is. Exactly what you'd expect from the docs.
There are tables, explanations, and links to other docs pages.
Very bold decision imho. It definitely makes them feel super developer focused.
Plus if you do want a more standard, enterprise stuff you see:
"If you need more support or compliance options, you can choose one of our paid plans. These come with usage included and additional support options."
And that page looks like a classic pricing page.
But they focus on the developer buying experience here. Super interesting.
How do you make your dev tool pricing simple?
I really like this one.
Saw someone share a pricing page from Userfront some time ago and really liked it. They changed it now but I really like the thinking behind the older version.
It is just remarkably simple while hitting all the boxes:
Just a very good baseline.
I like those sidebar CTAs from Auth0.
They go with a sticky Table of Contents which gives a better reading experience.
They put two CTAs below that TOC:
Solid job.
Mixpanel primary CTA is to take an interactive tour.
They take you to a 30min video + a guided UI tour.
Not a signup.
That is because with products that have long time to value (like analytics, observability etc) dev will not see value in the first session.
I mean to really see value you need to see real data, real use cases. And if you were to actually test it would take weeks.
That is why many companies do demos. But demos have their own problems (and most are bad).
Interactive tools make it possible for me to explore the value without talking to anyone.
I love this option.
Mux does a few things beautifully in this header.
Value proposition:
Animated visual that is really good for dev tools:
How easy it is to get started is a big conversion factor for any dev tool.
Devs want to test things out and if it is hard to do they will be gone testing a competitor that made it easy.
And so a good how-to section on your homepage can make a big difference in getting devs to that first experience.
Appsmith does it beautifully with their 1-2-3 How-to section:
It is so engaging and just beautifully designed. And the CTA to additional resources like integrations, widget library, and docs make the message land. I do believe it is easy to set this up.
Great pattern to copy-paste imho.
This is a sandbox experience folks over at Sentry.io created.
I like the navbar CTAs with a big "Documentation" button in there.
Reminds me that I can go and see it when I need it.
But I also get those conversion focused "Request a demo" and "Start a trial" for when I am ready.
On top of that I get tours and help in the sidebar for when I get stuck.
.... and the whole thing is gated behind a work email which I don't love.
But having that work email let's you nurture (and Sentry is known for awesome emails).
Plus it does help sales. If anything it is an additional signal for your account scoring models.
But if you are going to gate a sandbox, make sure to show all that value behind the modal like Sentry did.
With that I can feel compelled to type in that email.
How to communicate the flexible part of your plan?
Many dev tools have 3 plans:
Especially the ones doing some flavor of product-led-sales or open-source go-to-market.
Now, the Team plan is often a self-served version.
And for many dev tools, this part is partially or entirely usage-based.
So how do you present it?
You can just have "+ what you use" and explain it in the big table below.
But if you have just one usage dimension then why not do it here?
Resend does it beautifully communicating right away that it starts at 20$ / month and grows with the amount of emails you send.
Very clear. Very nice.
This is a nice little touch in the last step of the signup process.
Linear asks you to do two things:
The beauty of it is while this is an ask it is done so gracefully:
Nice and simple and I am sure it gets some folks to subscribe/follow.
An interesting option to push people to read the next article.
You use a slide-in triggered on a 75% scroll with a "read next" CTA in the bottom left.
On the aggressive side for sure but when the article you propose is clearly technical it could work.
And if your articles are not connected to the product explicitly you do need some ways to keep people reading and see more of your brand.
Devs have a love/hate relationship with "Book a demo" call to action.
Mostly hate though.
Especially if what they want is:
Let's just say that sitting through an hour demo call with a salesperson just to get the pricing is not what most devs love to do with their time.
But there are moments in the buyer journey when devs do want to have that live session:
Then, having a live session/demo is the fastest way to move forward.
@PostHog handles this dev journey reality nicely with:
This approach solves both scenarios really nicely.
Sometimes your product just wins on price.
I like how New Relic owns it on this page:
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.
Showing code and UI in an explainer video is always a dance and rarely ends well.
You want to show the code to make it devy.
But you don't want to show everything not to overwhelm.
The same goes for UI which should look like your UI.
But show only what is necessary.
It's a struggle but CircleCI does it really nicely in this explainer:
They do the same for the UI later in the video.Just a really clean way of explaining things. Nice!
Modal with updates.
Adding a modal with "what happened lately" for users who come back to the app.
Good idea for re-activating users by showing new features or examples.
+ a link to a deeper resource.
Need one more call to action idea for your dev tool blog?
How about starting an article with it?
Sounds weird but if done right it can work. Even with devs (or maybe especially with devs).
Earthly did and they are known for great dev-focused content.
Ok, so how does it work?
You start your article with a contextual call to action where you explain:
And then you let people read.
Those who find the topic important will remember you and/or maybe click out to see more.
I like it. It's explicit, transparent, and actually noninvasive.
Vs pages are a classic SaaS marketing.
But I like how Ably adjusts them to the developer audience:
Nice way to show code and results straight from the React docs that people love.
And this pattern can be used outside of the docs for sure.
Anyway, a classic situation:
And folks behind React docs solved it nicely by:
Not groundbreaking maybe but a beautiful implementation that is just a delight to use.
Subtle but effective dev blog CTA -> info box.
Basically a plain article in-text CTA but there is something special about it.
It looks like a docs info box.
It is not a "buy now" style call to action but rather a subtle "you may want to know about X" push.
But for it to really feel like an info box it needs to connect to the section of the section of the article around it.
Otherwise, it will just feel like an intrusive ad anyway.
PlanetScale does a great job here.
They link the part of the article about the sharding library Vitess with their product that was built on top of it.
It feels natural and I am sure it gets clicks and if not then product awareness.
"How fast do you ship?"
Not many dev tools answer that on their homepage. PostHog does.
In a typical (enterprise) sales process, people often ask:
And you show them the roadmap or get someone from the product on the next call.
But I haven't yet seen dev tools talk about it on their homepage.
But why not?
Devs who want to buy self-serve want to know it almost just as much.
After all, they won't be able to twist your arm to build that custom feature cause "we are your biggest client and we need it".
I like it, it builds trust, it shows me you are transparent,
And it shows me that those features I can see on the public roadmap will come true.
A nice example of making navbar more developer-focused.
Ask for GitHub stars with a link to the repository.
It does three things:
The problem with presenting API is that it is hidden. It gets the job done in the background.
So it is not "attractive" in the way some other dev tools can be.
But you can:
That is how Mux, video API, solves it.
Found this awesome crossover on their homepage.
They give you:
Love it!
I love the design of this crossover section on the Tailwind homepage.
I see the code and the result next to each other.
I see how I can get that result with code.
It is interactive and catches my attention.
It makes me feel inspired.
Great job Tailwind team!
Which feature/product to show in the header?
How about all?
Many dev tool products are feature-rich. And you want to show those awesome features.
But it is easy to overwhelm the reader when showing so much info.
That is why I really like the header tabs pattern that @PostHog uses:
This pattern is especially powerful when you want to communicate completeness.
Posthog definitely wants to do that. If you are on that train I'd strongly suggest considering/testing it.
Interactive product tours are all the rage.
But how do you make them work for the dev audience?
How do you deal with:
That is hard.
But Vercel somehow made it.
This is by far the best product tour I have seen so far.
What I love:
This product tour is what dev tool startups will aspire to for years (or months ;) ) to come.
Mark my words.
Funny ad, that makes fun of ads.
But it actually communicates that you don't care about the ads but more about something else, like:
"See docs" is one of my favorite secondary CTA on dev-focused pages.
TailwindCSS takes it to the next level by inserting docs search right into the header CTA.
This takes devs directly to the page they are interested in rather than have them try and find things for themselves.
They could have searched the docs in the docs, of course.
But this is just this slightly more delightful developer experience that TailwindCSS is known for.
Sometimes you have an article, report, or event you want to drive people to.
And it is important that they read it.
What Plaid did here is an interesting way of putting it right in the hero section without making it overwhelming or distracting.
I like it.
Interesting dev blog CTA idea from V7.
CTAs in technical articles is a tricky subject:
I like how V7 approached it here:
What I'd change/test is making this CTA not a generic value prop but something closely connected to the rest of the article.
There are a few developer experience gems here:
Also, their design is super clean, non-invasive, and simple which makes for easy content consumption and more developer love.
How to show integrations on your dev tool homepage?
Every dev tool needs to integrate with other libraries in the space.
And you want to show how well integrated with the ecosystem you are.
But you ctually want to do a bit more than that.
You want devs to see how easy / flexible / clean it would be for them to use it.
That is why instead of showing just logos from your ecosystem it is good to show the code too.
Meilisearch does that beautifully:
I am sure this is getting more clicks than just a list of logos.
If your dev tool's USP is that it is faster -> Show it in the header
I like how folks from Bun focus on the fact that they are a faster library.
They show the benchmark as the key visual on the homepage header.
I love it.
If you think about it how else do you really want to show that you are faster?
This is believable, especially with a link to the benchmark so that I can dig deeper.
They show competitors, they don't pretend they don't exist.
And they talk about being faster left right and center.
I mean, they drive this "we are faster" home for me.
If that was important to me, I'd check it out.
Simple and powerful messaging.
They say what they do. Zero fluff.
They make it easy for devs by explaining how they are different than (obvious) competitors.
They add a little developer-focused social proof.
OK, the best way of getting GitHub stars is by creating a project that solves real developer problems well.
I assume you have done that already and the metric that people love to hate ⭐ is growing organically.
What do you do now?
I mean you got to ask people in one way or another.
Many companies put it in their navbars or hello bars.
Posthog adds a sticky banner at the bottom of the page that follows you as you scroll.
It also shows a start count which at their size (11k + stars) acts as social proof.
You can close it and the next time you visit the page it will be off not to push too much.
I like the concept makes sense to test it out this way imho.
Very nice design solution on the homepage.
Classic communication of the world before using your tool and the world after.
Really liked how it felt messy before.
And is nice and clean after.
This is one of the more devy blog designs I've seen in a while.
It has this docs-like feel.
But is just a bit more fun and loose than most docs would allow.
Here is what I like:
And if your posts are code-heavy, then a docs-like experience is where you want to be anyway.
But you can spice it up with things that wouldn't fit the docs.
Like a Twitter/X embed or a meme.
What to put in the header when your dev tool does a lot?
I like how Appsmith approaches it.
In their case, they have multiple use cases they want to showcase.
But you could use the same idea for many features or products.
Show multiple clickable tabs:
A bonus idea is the "Try cloud" | "Self-hosted" CTA.
It communicates right away that you can deploy that dev tool anywhere.
If the self-hosted deployment is important to your customers let them know.
You don't want them to look for it and drop from the page trying to find the FAQ.
Adding CTA in dev-focused articles is hard.
You don't want to be too pushy, but you do want to get conversions.
DigitalOcean strikes a great balance with its in-text article CTA design.
They make this CTA look like an info box that you'd typically see in the documentation.
It is clear that it is a Digital Ocean CTA but it doesn't feel pushy.
It feels like a piece of potentially useful information.
Love it.
How to bring attention and trust to a feature section?
Add a testimonial.
Ideally, it should talk about that feature to make your message even stronger.
I like how Appsmith made it animated and it just makes you look.
And you read the testimonial and look at the feature above it.
Good stuff.
How to present benchmark results masterclass from RavenDB
The biggest problem with the software benchmarks that you run is?
People don't trust you. Especially when the results are good.
𝗬𝗼𝘂 𝗷𝘂𝘀𝘁 𝗻𝗲𝗲𝗱 𝘁𝗼 𝗯𝘂𝗶𝗹𝗱 𝘁𝗵𝗮𝘁 𝘁𝗿𝘂𝘀𝘁. 𝗢𝗻𝗲 𝗼𝗳 𝘁𝗵𝗲 𝘄𝗮𝘆𝘀 𝗶𝘀 𝘁𝗵𝗿𝗼𝘂𝗴𝗵 𝘁𝗿𝗮𝗻𝘀𝗽𝗮𝗿𝗲𝗻𝗰𝘆.
People from RavenDB do it by:
This looks solid because it feels like I could re-run what they did myself.And so I trust them and I probably won't ;)
How to present many features at once?
Sometimes your dev tool has many features/products that you want to show.
❌ Showing all of them as separate sections doesn't work with more than 3. It just gets too long very quickly.
✅ You can go with the tabs pattern where each tab has copy+visual for a feature.
💡 But there is another option that makes a ton of sense when you have many features to show.
Interactive tiles of different sizes.
💚 I like the implementation of that pattern coming from Clerk:
That pattern can work really well on blogs or learning centers too but I think we're going to see more of it on dev tool websites.
Linked GitHub logo in the navbar
Adding CTA to your GitHub repo makes your company look more dev-friendly.
If you have a ton of stars I'd show those as well to play that social proof card.
But even without it, I think it's a good way to get more traffic to your repo and get those stars :)