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.
A classic dev tool blog call to action that is somewhat underused these days.
Was going through Martin Gontovnikas blog and found a post from a couple of years back.
He called this "Aside CTA" and the idea is this:
Why this can work well with devs is:
Definitely a classic that is worth trying.
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.
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.
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.
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.
One of the top-performing conversion flows in dev-focused articles.
"Aside CTA" in the "How to do {jobs to be done}" article.
You know the drill:
And Export SDK executes it (almost) perfectly:
One thing that could be tested and changed is putting this "Aside CTA" mid-article and not at the end (tip from Martin Gontovnikas).
A good thing to try if you are running the "How to do {jbtd}" article strategy.
This is how you write dev tool JTBD blog posts.
Masterclass of writing this type of content from @WorkOS imho.
Deep 2000 word guide that explains how to add webhooks the your application.
Goes into examples, best practices, everything.
One thing it doesn't do?
It doesn't push the product left right and center.
In fact, the only CTA is hidden in the very last sentence of the very last section.
Why?
Because most likely, the reader's intent is around understanding the problem at this point.
They want to understand what adding webhooks to their app really means from the practitioner's standpoint.
And they did that beautifully.
Could you have pushed the product a bit more? Sure.
But by answering the actual questions devs came here for they managed to build trust.
And I am sure got their fair share of click-throughs and signups anyway.
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.
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).
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.
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.
The idea behind this conversion play is to put an "Aside CTA" that is unrelated to the content early in the article.
And get that clicked.
But obviously, if you do that it will be pushy and intrusive.
So?
Nevo David from Novu shared this idea on one of the podcasts:
Btw, Nevo says that cat memes work best.
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.
This is one of my favorite our dev tool vs competitor blog posts.
With these pages, you want to explain when you are better.
But you don't want to berate your competitor.
And above all, you want to help people make a decision.
Chances are (almost 100% ;)) that you are not better for every use case. And your developer audience knows it.
But there should be use cases, tool stacks, or situations when you are the best option.
Talk about those. Dev to dev.
@Convex did a great job in this post that I think can be a template for how to write these:
After reading that post you are fairly convinced that if your situation matches the one described and if it makes sense to use it.
Love it.