Streaming came along and changed the game, bringing us time-shifted, bingeable shows. The “what’s on channel 4 at 8 pm?” appointment television was replaced with “what should I watch next if I liked White Lotus?” 

A similar pattern is emerging now, with developers increasingly using AI over traditional search engines to find new products.

For years, winning your category meant you earned the developer mindshare. The top spot as an analytics database or security monitoring tool gave you a steady supply of developers to nurture into customers. 

That logic still holds for many category queries, but we’ve noticed a shift in LLM recommendations. The old approach breaks down when developers get specific. They’re searching with more context than your category positioning was built to handle.

Category Leaders Don’t Always Survive Context

It’s still a great time to be a category leader. Once a dev tool holds the top spot in developers’ minds, it fades slowly, if at all. The same pattern plays out with LLM recommendations, perhaps even amplified. 

A model’s training has seen so many questions, answers, and odes to top products that they seem to remain in the conversation even after developer sentiment has passed. 

But the more specific queries are less likely to have this same staying power.

LLM Rank tracks hundreds of dev tools in dozens of categories. Prompting models with the real questions developers ask, we’ve seen the leaders hold steady for category queries, but observed a lot of reshuffling when looking for use cases, alternatives, and tech stacks.

In fact, 74% of contextual queries get a new leader, while 30% return a completely distinct top three.

About half of the top 10 are replaced when we compare category to contextual queries across models. In open source, where developers frequently look for products to solve their problems, it’s even clearer. On average, only two category leaders remain in an open source top 10.

In one case, open source searches displaced the entire top 10. They were replaced by:

• Five products from low on the category leaderboard
• Five new products that appeared for the very first time

Every category leader was gone. Only the contextual leaders remained. And contextual queries are growing as developers realize that they can get more precise answers. You want to be on the leaderboard the developer finds when they’re ready to build.

The Query Already Contains the Context

In the SEO era, marketers thought in common search terms. Short, categorical, high-volume keywords were the norm. The job was to translate this minimal information into search intent and eventually convince developers to try your product. While this type of search is not gone, longer queries are steadily replacing it, leaving room for rich context.

One window into this trend is now integrated into Google searches. In about 50% of these, the “top result” is an AI overview. When a user clicks into it, they enter AI Mode, where the response can be further refined. 

Google’s own data shows that these AI queries are getting longer and more specific. They’re asking “what,” “how,” and “can I” questions.

3x longer: Google reports “the average AI Mode search query is triple the length of a traditional search query”

For developers, it means they’re less likely to turn their problem into keywords. They’re providing the full context of that problem within the query itself.

Keywords vs Contextual Search

On Google, the lengthy query is bound to trigger AI Mode. And when coding agents receive these questions, they fire back with recommendations and implementation steps.

Coding agents like Cursor, Copilot, and Windsurf construct queries automatically from a developer’s stack, language, and dependencies. The developers aren’t obliged to translate their problems into a query. It arrives pre-loaded with even more context the developer didn’t have to type.

We’ve tracked similar identity and authentication recommendations from the top LLMs. Consistently, they include these products in the top five: Auth0, Firebase Auth, Okta, Amazon Cognito, and Clerk. Since Okta owns Auth0, there’s a single company frequently fighting with itself at the top of that leaderboard.

But that’s for a category query. Add some additional context and the picture becomes clearer. For example, when developers look for enterprise single sign-on (SSO), they’ll see that Okta now leads the pack. As we saw in the previous section, much of the pack itself has also changed:

Only one other product from the category top 10 makes the SSO-contextual top 10. The rest are mostly filled in by products ranked 11th through 25th. Two new products appear, which were previously invisible across the dozens of category searches we performed.

While it’s useful to see category leaders, the contextual results are where developers envision real solutions to their problems. The context comes from the words the developers use and sometimes the codebase they’re building. The question is whether your positioning shows up inside that context, because that’s what determines whether the LLM recommends your product.

Your Positioning Has Gaps the Data Can Show

Most developer tool companies compete in large categories, such as Cloud Compute or Observability. A handful of category products duke it out for the top few spots, each carving a distinct position. But to what extent does that match what the LLMs think?

Contextual queries show how well positioned your dev tool is with LLMs. AI Coding tools are a clear example of positioning in action, with the gaps visible in the data. 

The category leaders are Cursor, Copilot, and Windsurf. Seemingly missing from that list? Claude Code, which has become a developer favorite. It’s ranked ninth overall: OpenAI only recommends it 60% of the time, Claude ranks itself fourth behind the category leaders, and Gemini doesn’t recommend it at all.

Most of that changes when a contextual query requests an AI coding CLI, the primary interface developers use for Claude Code. Now Claude is the top recommendation: OpenAI suggested its rival in every single one of our tests. Claude gets some confidence and puts itself right up at the top.

Gemini’s silence on Claude Code isn’t an anomaly. This kind of disagreement between models is common in our tests. In fact, it could be a reason that you don’t notice the gaps in your positioning: when you check one model, you only see a single point of view.

50% of the time, asking a second model returns an entirely different top three.

One model is not enough to know if your positioning hits. Most teams don’t perform this sort of sanity check against their positioning. Because this data is publicly available, you can run it on your competitors to see how they perform in their apparent positions, as well as against your product in areas where it should be strong.

Here’s how four AI coding tool marketing teams might react to these results:

• Claude: “We showed up where we’re strongest!”
• GitHub Copilot: “We may slip a little, but we’re still in the CLI conversation.”
• Windsurf: “The IDE context is better for us, anyway.”
• Cursor: “What the heck, why does the Cursor CLI get overlooked?!”

Any one call to an LLM may be nondeterministic, but you can find solid facts within the data if you approach it right. The gaps in your positioning are mappable and often fillable, but only if you look at the complete picture.

How Well Does Your Positioning Survive the Query?

Nobody canceled their TV Guide subscription because they stopped watching television. The time and channel format no longer supported how viewers found a show. Category leadership in dev tools won’t go away, but it’s no longer the whole game. 

When developers look for tools like yours, they’re likely to include context that changes the recommendations they receive. Whether your product appears in those results depends on how well your language reflects how developers describe their problem when they’re ready to build.

EveryDeveloper built LLM Rank to show both category and context in developer search. We work with dev tool companies to help close the gap between how they position themselves and how LLMs actually recommend them. 

Let’s start a conversation about your product and the developers you want to find it.

If your dev tool competes in this space, you want to know whether you’re on that list of recommended products.

That’s why we built LLM Rank, a site to track how LLMs recommend dev tools. 

We ask real developer questions to Claude, OpenAI, and Gemini, then combine the responses. The results are a free ranking of 781 products across 33 categories, updated monthly. 

We’ve been assembling this data all year and have three lessons to share so far:

1. One query is an anecdote, not a pattern.
2. Word choice moves rankings more than you’d expect.
3. How you rank reveals more than where you rank.

Whether you appear on the lists at the bottom, top, or not at all, you can put these ideas into action to ensure developers actually discover, adopt, and trust your product.

One Model, One Prompt, and One Request Are Not Enough

A client told me what happened when the topic of AI-assisted search came up at their company’s retreat: a dozen people opened their laptops, typed a few words into their favorite LLM, and got twelve different answers. Some results mentioned their company, many highlighted their feared competitors, and others seemed barely related to the product’s primary category.

The marketer or product manager who runs a test prompt against a single LLM will either put way too much stock in the results or completely dismiss them. Both are mistakes.

That’s because AI results vary in multiple ways.

Variance Across Models

The experimentation and feature flagging leaderboard has a well-known #1 in LaunchDarkly. In our repeated tests, it was returned first by every model, every time. 

The rest of the list shows much more variance: Split (#9) shows up in only 40% of our OpenAI tests, but lands in the top 10 because Gemini and Anthropic consistently rank it as the runner-up.

Model-specific ranking of experimentation dev tools from llmrank.fyi

If a Split marketer relied solely on ChatGPT, they would panic. If they checked only Gemini, where Split sits solidly above Optimizely, they would feel confident. Neither view is wrong. Neither is the whole picture.

Variance Across Requests

Even within a single model, the same prompt produces different answers from one run to the next. That’s the nature of LLMs.

To create the LLM Rank leaderboards, we run each prompt through 10 requests across the latest version of the top three providers. Those 30 data points provide a comprehensive view that doesn’t come with one-off queries in your AI chat window.

Variance Across Prompts

Then there’s the prompt itself. Many dev tool marketers ask the question they wish developers would ask:

“What natively architected AI database is simpler, faster, more secure, and more trustworthy?”

That’s something a marketer writes, not a developer. When you pull copy from your sanitized positioning statements, you risk missing the dev’s real language — the kind they use several hours into a Cursor session when they realize their local solution won’t survive production.

Takeaway: A single query against a single model on a single day is a data point, not a signal. Judge your standing across many queries, models, and developer language.

The prompt also reveals something about the person asking it.

Personas and Use Cases Have Never Mattered More

Two developers in the same category can get completely different recommendations from the same model. While that might be frustrating, it’s actually good news for marketers. The tools you’ve built to understand your audience are even more useful now.

When marketers thought in search terms, the top of the funnel was a winner-take-most affair. Show up #1 in the core search, and Google would likely rank you near the top for much of the long tail. LLMs, by contrast, are non-deterministic and context-aware. The slightest change in language or stated use case can substantially move the leaderboard.

Personas and use cases can help you filter for meaningful results.

Same Category, Different Persona

The content management leaderboard has been remarkably stable. Roughly the same players hold the top five month after month. That all changes when you ask for a headless CMS that’s open source:

Open source CMS data from EveryDeveloper’s internal dashboard

Four of the original top five disappear entirely. Strapi (#3) jumps to the top. Directus (#7), Payload CMS (#14), Ghost (#12), and Keystone (unranked) fill in around it. For the open-source developer persona, the canonical “top five” is essentially the wrong list.

Same Persona, Different Use Case

Now imagine you have a developer building location-based apps. They may look up nearby restaurants by cuisine (geo discovery). Then, they’ll retrieve a user’s location and convert that to an address (geolocation) for delivery.

Compare the geocoding leaderboard to geo discovery:

Geocoding vs Geo Discovery shows how use cases can change the leaderboards

Though some of the names are shared, there are important differences. The most notable is Foursquare, which doesn’t even rank on the geocoding leaderboard. That’s because the product supports place lookup by name or category. It’s not built to convert between addresses and coordinates.

Different use cases, different rankings.

Categories Sliced by Personas and Use Cases

The best developers for your product ask LLMs for recommendations. They get responses that are highly contextualized to their stack, organization, and the thing they want to accomplish. You don’t need to buy the top slot of a high-volume search term when you rule the results for the right developers.

These persona and use case slices aren’t published on LLM Rank yet, but they’re where we’re headed. There’s no single leaderboard for a product category. There are many ways developers ask, and many opportunities to earn a recommendation that the top-line view could miss.

Takeaway: Find the position where you actually compete. If your buyer cares about open source, self-hosting, or a specific stack, that’s your scorecard.

Where it gets really fun is when you compare these slices and take note of the differences.

Find the Gaps Worth Filling

When my Portland newspaper interviews local candidates, the question I always read first is, “Who would you vote for, other than yourself?” The answers are often more revealing than the rest of the interview combined. The same trick works on LLMs. The most useful information isn’t in any single ranked list. It’s in the gaps between lists.

There are many ways to see and identify these gaps.

The “Alternatives” Lens

Cursor sits atop the AI coding IDE leaderboard. GitHub Copilot and Windsurf are virtually tied for second. But ask for alternatives to each of these three, one at a time, and a different name keeps appearing.

Tabnine, ranked #7 in the core category, shows up in 100% of alternative searches across all three tools. Nothing else does. Tabnine isn’t winning the headline race. When it comes to the question developers ask when they’re already unhappy with an incumbent, it’s the most consistent answer in the category. That’s a meaningful position — and it’s invisible from the leaderboard alone.

The “Model Delta” Lens

Comparing results across models reveals editorial fingerprints: When we looked at AWS competitors, Azure was mentioned in every OpenAI response and zero Gemini responses.

“AWS competitors” by LLM provider

Whatever the cause, the implication is real: the model your buyer uses will change which competitors appear beside you.

The “Positioning Gap” Lens

Finally, compare what you say your product does with what LLMs say it does. Your positioning implies a narrative. If you’ve communicated it well, LLMs should agree. You’ll rank well in the use cases you emphasize, weaker showings in the ones you don’t.

Reality is usually messier. When we analyze LLM competitive data with clients, we frequently uncover gaps and opportunities they wouldn’t see otherwise. That popular developer use case that your product supports might not show up in LLMs if you’ve rarely covered it in marketing and documentation sites.

Takeaway: Look at the differences between rankings. Each one points to a different gap, and each is an opportunity to fill.

The right questions naturally expose exactly where to focus.

Know Exactly Where You Rank

That developer with the broken dashboard got a recommendation right where they were building. Whether a product appeared on that list depended on decisions made months earlier. Whether LLMs recommend you depends on what you write, how developers talk about you, and which use cases your content covers.

None of that is visible from a single test query. You can only see it when you look at the pattern across models and with the real developer use cases in their language.

Three ways to put this into practice:

1. One query is a data point. Trust the pattern across many.
2. The category leaderboard is a starting point. Slice by persona and use case.
3. The most useful signal lives in the gaps. Find the ones worth filling.

LLM Rank is the public, free version of this work. Browse it, find your category, and see where you stand. It’s updated monthly, so you’ll always be able to see how LLMs respond to developer questions.
If you want the slices that aren’t on the public site yet — your persona cuts, your alternative queries, the gap between your positioning and what LLMs say — that’s what our LLM Reach Assessment is for. Stop guessing where you stand in AI. Find out exactly.

Most developer tool companies are unknowingly making it hard for AI to recommend them. There are three stages where this breaks down. We’ve found that most companies have gaps in at least one of them.

The stages:

• Discovery: when devs find products in AI search.
• Evaluation: when devs compare products with AI.
• Adoption: when devs ask AI to help with implementation.

For each stage, we’ll share examples, gaps, and actions you can take to reach more developers.

Why Your Dev Tool Isn’t Showing Up in AI Search

When developers look for new solutions, they won’t mention your product. They won’t even mention the great benefits you worked so hard to articulate.

Said no dev ever:

I need a database platform that seamlessly integrates into my workflow so I can sleep well at night.

And yet, that’s what many developer marketing landing pages look like.

AI assistants are often the first stop for developer research. But LLMs can only surface your tool if your content reflects how developers actually describe their problems.

Here’s what happens when developers search with AI:

1. The developer describes their issue to an AI assistant.
2. The AI searches its training data for concepts related to the query.
3. The AI recommends products that use the problem language.

Will AI recommend your product or your competitor’s?

Example: A developer struggles to debug when logs are scattered across multiple services. Your “centralized observability platform” solves this problem, but only if you use real developer language. If a competitor discusses distributed tracing or structured logging and you don’t, the AI is more likely to reference them in developer searches.

This isn’t just a content problem. It’s a perspective problem that affects everything from your landing pages to your docs.

Action: List the most common problems your tool solves and use those exact phrases across your landing pages, docs, and blog content.

Getting found is step one. But once a developer finds you, they’ll ask much harder questions. That’s where the next gap appears.

How You Lose Devs During AI-Assisted Evaluation

Congrats — developers have found you! Now they need to know if you or your competitors can solve their problem.

They’re not browsing features pages. They’re describing exact use cases to an LLM:

Which tools handle webhooks with retries? Do any prevent duplicate messages?

Here’s where evaluation breaks down: 

Feature lists tell the AI what your tool does, while use cases tell the AI how and when it does it — and developers are asking “how” and “when” questions. You need specifics, or developers move on.

Example: Your “reliable event processing” feature addresses duplicate webhook deliveries. Meanwhile, a competitor provides a complete example of idempotency key implementation with error handling. The AI walks the developer through the competitor’s approach in detail.

Developers aren’t evaluating marketing claims. They’re testing whether your tool fits a project they already have in mind. The more precisely your content reflects real implementation situations, the more confidently AI can recommend you.

Action: Create content around real scenarios. Authentication flows, error handling, and retry logic show not just what your tool does, but how it behaves when things get complicated.

Getting found and getting evaluated are two hurdles. But when developers are ready to build, they’ll ask AI to write the code for them. That’s where we’re headed next.

When AI Knowledge Gaps Stop Developer Adoption

Developers are convinced. Now they’re working in their editor, asking AI to help them get started with your product. 

This is the moment your documentation comes into play. If the LLM understands your product or can quickly get the context it needs, it can help developers succeed. If not, the AI assistant may block adoption.

Here’s the adoption scenario to avoid:

1. A developer asks AI to write code to adopt your product.
2. An LLM delivers an outdated version based on its training.
3. The code throws an error across the developer’s terminal.

Incomplete examples and missing context produce broken code. But that doesn’t have to be the end of the story: The developer pastes your docs into the conversation to help fix the initial problems. Will they help or will they hurt?

Example: An LLM uses outdated training data to connect an SDK, resulting in incorrect method names or deprecated parameters. Updated documentation can fill these gaps, but only if it’s easy to find and provide to the AI assistant.

Preparing your docs for AI systems is what separates the tools that get adopted from those that don’t. The bar is higher than most teams realize. Developers need docs that are findable, contextual, and ready to drop into a conversation.

Action: In addition to keeping your documentation up to date and accurate, include a “copy for LLMs” button on every page.

Developers who can quickly get accurate context for their AI assistant will succeed with your product. Those who can’t will move on to something easier.

Have you identified your blind spots yet? That’s exactly what we can help you figure out.

Where You Stand When Developers Ask AI

Discovery, evaluation, adoption: three stages where developers can slip away. Most developer tool companies have at least one of these blind spots. Many have all three. The hard part isn’t fixing them, but knowing exactly where you stand.

That’s exactly what our LLM Reach Assessment shows you. We test what AI actually says about your tool at each stage of the developer journey. See how your product compares side-by-side with your competitors, just as developers will in their AI searches.

Stop guessing at your AI visibility. Get your LLM Reach Assessment and find out exactly where you stand.

There was a time these questions would send developers to Google, then to blog posts and documentation. Now, changing developer behavior and search engine results force action, even without a definitive playbook for LLM content strategy. Do nothing, and your product becomes invisible to this growing discovery channel.

Leading developer tool companies like Vercel, Stripe, and Postman have already developed effective answer engine optimization (AEO) and generative engine optimization (GEO) strategies. We identified five practical patterns you can adapt to build a content strategy that works for both human developers and the AI systems they rely on for answers.

At the center of these strategies is a simple llms.txt Markdown file that helps LLMs understand and recommend your product. The real insight isn’t the format itself. It’s what companies choose to include in it. We researched 30+ of these files to learn what matters most. Approaches vary dramatically: explicit AI instructions, use-case libraries, or careful access controls.

We’ll start by explaining llms.txt and why it’s becoming a standard. Then, we’ll break down five distinct approaches companies use with this file, so you can get your product in front of AI systems.

Where AI Content Strategy Starts for Developer Tools

You might already be familiar with robots.txt files, which provide URL patterns that indexers are allowed or disallowed to access, and sitemap.xml files, which list every URL, in no particular order, to help search engines fully index your site. 

But these pre-AI formats don’t solve the challenge that LLMs face when crawling your site: thousands of pages with no clear hierarchy or starting point. The llms.txt file solves this with curation and context. 

The companies we reviewed use llms.txt to guide AI toward their most important documentation, getting started guides, and integration examples. Here’s a subset of GitHub’s llms.txt.

The format has seen rapid adoption, even as some SEO experts question whether LLMs use these files. A Reddit thread from June 2025 noted only 3,827 sites using llms.txt. By November that year, the number had jumped to over 1 million sites.

Even as we completed this research, more dev tool companies opted to include an llms.txt file. There is at least one llms.txt file for 75% of the dev tool companies we analyzed.

The llms.txt format isn’t a silver bullet for AI discovery. It won’t compensate for poor documentation or unclear product positioning. But it forces a valuable exercise — identifying what content matters most to the audience you want to find you. That curation process helps AI systems, developers, and your own team better understand your product.

So where do you start? With the problems your product solves, not the features it offers.

1. Frame Around Use Cases for Discoverability

Instead of “I need a tunneling solution,” developers are more likely to think “I need to test this webhook.” This is why use-case-driven content works: it matches how developers describe their needs. For llms.txt files, this principle becomes even more critical. When developers ask AI assistants for help, use-case framing helps your product enter the conversation.

While tunneling tool ngrok includes extensive internal product documentation for LLMs, it devotes an entire section to other companies’ products. More than 60 guides cover major platforms like GitHub, Heroku, and MongoDB. ngrok positions itself as the invisible infrastructure that enables these tasks — and a solution to common developer workflows.

The ngrok llms.txt shows they know how developers think. Their OAuth and webhook guides don’t mention ngrok in the titles. Instead, they focus on the task itself: authenticating users or testing webhooks locally.

Though not to the extent of ngrok, other companies take a similar approach. DigitalOcean, for example, organizes llms.txt content around common scenarios with Kubernetes, MySQL, and Kafka rather than solely around its product features.

Both companies understand a key insight: AI-assisted discovery happens when developers describe problems, not product names.

To apply this strategy, audit your documentation titles and llms.txt categories. Do they use your internal product terminology, or do they match how developers describe tasks? Replace “Authentication API” with “How to add OAuth to your app.” Replace “Database Management” with “How to optimize MySQL performance.”

When you frame around use cases, you enable discovery. But once an AI system finds your product, how do you guide what it recommends?

2. Give Explicit Instructions to LLMs

AI systems are powerful, but they’re not perfect. They can recommend outdated APIs, suggest deprecated features, or miss critical implementation nuances. Without guidance, an LLM might point developers toward the wrong solution — even if your documentation clearly explains the right approach.

Stripe has a track record of reducing friction by being exceptionally clear with developers. They apply the same philosophy to AI systems. Their two llms.txt files — one on the primary site and another for documentation — tell LLMs what’s important to know.

In fact, Stripe even calls out to the file in its docs footer, ensuring its discovery.

Opening up the file, Stripe’s instructions are precise.

Stripe structures their llms.txt strategically: resources first, then explicit instructions. After listing documentation and API references, they provide detailed guidance on everything from API selection to compliance scenarios to platform architecture.

For example, they warn against the deprecated Charges API and direct AI toward Payment Intents (including migration instructions). This level of guidance prevents AI from recommending patterns Stripe no longer supports.

Stripe was the only company we found that speaks directly to AI systems. But the broader lesson is about providing rich context, not just links. 

Postmark demonstrates this through comprehensive documentation: they embed complete API reference sections with inline code examples, request formats, and error handling.

Both Stripe and Postmark provide key context, enabling LLMs to answer implementation questions without fetching external documentation. For your llms.txt file, identify what’s most critical for AI to understand about your product: which APIs or features to recommend, which approaches are deprecated, and what patterns lead to success. Then create a dedicated section that provides this context.

Providing rich context helps AI recommend your product correctly. But some companies take a different approach: controlling what AI can do with that content in the first place.

3. Explain What LLMs Can (and Can’t) Do

LLMs interact with your content in two primary ways: training on it to build their models, and accessing it directly when answering questions. Most companies prioritize maximum AI visibility and treat both modes the same. Others take a more nuanced approach, setting different rules for training versus direct access to balance discoverability with control.

Snowflake shows us how this works in practice. The company provides an llms.txt file for AI systems, but it includes restrictions. LLMs cannot train on their documentation. Any commercial use requires explicit licensing.

Snowflake created its llms.txt to communicate permissions, specifically, “how AI crawlers and researchers may use content from docs.snowflake.com.” Unlike other companies using the file to guide AI toward content, Snowflake uses it to set boundaries.

This protective stance likely serves multiple purposes. IP protection is one reason. Accuracy is another. If models train on outdated docs, they recommend deprecated features. Blocking training while allowing direct access ensures developers get current information. It’s a different path to Stripe’s goal of guiding AI toward correct implementations.

The only other example we found with training permissions came from Render. In contrast to Snowflake, Render gives LLMs broad access to its content. In a “permissions” section near the top, the llms.txt file allows training, summarization, and commercial use. It also requires attribution, something it has in common with Snowflake. Render maximizes LLM visibility while requiring attribution, offering a middle-ground approach between full restriction and unlimited use.

The difference between these approaches isn’t just philosophy — it’s clear communication. Snowflake blocks training but allows access. Render welcomes both but requires credit. Neither company leaves its stance ambiguous. For your llms.txt, add permissions clearly stating your requirements: what you allow, what you restrict, and what you expect in return.

Even with the right access rules, AI systems still need usable content. That brings us back to fundamentals.

4. Use Developer Experience Best Practices

What works for human developers also works for AI systems. Clear hierarchy, logical grouping of related features, and building from simple to complex aren’t just human-friendly practices. As we reviewed llms.txt from top dev tools, we saw that LLMs need these same things to understand and recommend your product effectively.

Developers often mention Vercel for its great developer experience. The company’s llms.txt applies these same principles. The file opens with Getting Started, the essentials every developer needs first. 

Frameworks and tools come next. Detailed sections like API Reference and Knowledge Base appear later. Vercel gives the basics before advanced features, and concepts before technical details. It doesn’t try to cover every potential feature. Instead, Vercel’s llms.txt is a curated, prioritized summary offering quick help to any developer or agent reading the file.

Elastic takes a different approach to the same idea. The file organizes around the developer journey:

• Elastic fundamentals
• Solutions and use cases
• Manage data
• Explore and analyze
• Deploy and manage
• Troubleshoot

Elastic maps its content to how developers work.

Good developer experience principles are flexible, as long as you focus on your audience. Whether a human or an agent, the end evaluator is a developer with a problem to solve. For your llms.txt, include what they need: clear starting points, prioritized information, and intentional organization.

These principles help developers and AI systems navigate your content. But first, you need to decide what content to include.

5. Curate Your Content with Categories

Curation involves answering two questions: what to include and how to organize it. The companies with the most effective files prioritize essential content and use categories that developers understand. Your product likely has hundreds or thousands of content pages. You can’t include everything in your llms.txt, though some may try. 

Some companies skip curation entirely. Firebase and Algolia each provide 5,000–6,000 lines of uncategorized links with no apparent prioritization. MongoDB, on the other hand, includes hundreds of sub-headings across its 25,000 lines. Unfortunately, those categories are simply product names and version numbers. These companies have treated their llms.txt as a sitemap, assigning equal weight to everything. Their products are less discoverable because they’ve left LLMs to decide what matters most.

Netlify shows what’s possible in only a 120-line llms.txt file, which starts like this.

That brevity isn’t accidental. Netlify includes only what’s most important, not every feature or API endpoint. Then, they organize categories to match developer language. There’s a section for “Data & Storage,” not the branded name “Netlify Connect.”

For your llms.txt, include what developers need to get started and solve common problems. Then organize using categories that make sense in developer language, not internal product names or version numbers.

The pattern across successful llms.txt files is clear: they’re strategic, curated, and built with developers in mind. Yours can be too.

Make Your Developer Product LLM-Friendly

Leading developer tool companies use five strategies to make their products discoverable to AI systems: use-case framing, rich context, clear permissions, DX structure, and thoughtful curation. These are research-backed patterns that you can implement today.

You’re not starting from scratch. These strategies share a foundation: understanding your developer audience. You need to know which use cases matter, what context developers need, how they prefer to learn, and what information helps versus overwhelms. 

This knowledge should drive every decision in your content strategy, whether it’s llms.txt, documentation, or thought leadership. Just one of these patterns can help you reach developers through AI assistants more effectively.

Of course, implementation takes work — and that’s where EveryDeveloper can offer support. We specialize in understanding developer audiences and translating that understanding into effective content strategy. We can help you implement these llms.txt strategies, audit your existing approach, or work with your team to better serve both your developers and the AI systems helping them.

Let’s partner on your LLM content strategy and make your product more discoverable to AI systems. See how to work with us.

The problem goes beyond expanding your audience. You must understand the complex buying journey your product creates, in which developers, product managers, engineering leaders, and executives all play different roles at different times.

This article contextualizes the developer’s role in the process of adopting new dev tools. Understanding devs’ — and other organizational actors’ — levels of involvement will help you create a content strategy that works for decision-makers across the board, from the developer champion to the engineering leader they’re trying to convince.

Technical Problems Attract Multiple Audiences

The CTO at your potential customer sees slow deployments as a technical optimization problem. Their product teams see them as a competitive disadvantage. And their developers? They’re annoyed because of the daily productivity killers hindering them from doing great work. The broken CI/CD pipeline is the cause of all these issues, but each team views it from a different angle. 

To maximize your influence, your marketing must consider all the above perspectives, and more:

• Security worries about deployment vulnerabilities. 
• Customer success sees deployment delays as missed launch commitments. 
• Sales feels the impact when prospects ask about deployment frequency during demos. 
• Finance wants to understand infrastructure cost implications.

Suddenly, you’re not marketing to just developers — you’re marketing to half the organization. It’s enough to make any marketer want to retreat to feature lists and technical specifications.

The instinct is to solve this by creating different campaigns for each audience — CTOs get business case content, developers get technical tutorials, security gets compliance checklists, etc. 

The real challenge is translating between the audiences. When the CTO says ‘improve deployment reliability,’ their developers hear ‘reduce build failures.’ When their product team says ‘faster time-to-market,’ their DevOps team thinks ‘automated rollback capabilities.’ Your marketing needs to bridge these different ways of thinking about the same underlying problems.

These translation challenges matter because technical decisions increasingly involve non-technical audiences. Engineering managers need to justify tool choices to finance. Developers must explain deployment delays to product teams. CTOs present infrastructure investments to executive leadership.

Know Your Developer’s Role (and Help Them Play It)

Understanding multiple audiences is the first of several challenges. You also must determine where developers fit into this complex web of teammates. Their role changes based on your product, their company, and the stage at which you reach them. 

In some deals, developers are your primary champions, driving adoption from the bottom up. In others, they’re the final gatekeepers who can kill a deal after months of business-focused selling.

In the EveryDeveloper marketing continuum, we identified the developer focus of a product:

At the start of the continuum, a developer may only implement a product. At the other end, the developer is the most important (and sometimes only) audience. When we translate these stages to the roles developers play in the buying process, you can start to predict how other audiences will get involved.

These five dev roles will impact your marketing strategies:

• Implementer: With developer-enabled products, developers inherit and deploy solutions chosen by engineering leadership or procurement.
• Consultant: Developers are brought in during evaluation to assess technical feasibility and implementation complexity.
• Supporter: Developers engage early because your product affects their work, even if its primary purpose is to solve a broader organizational problem.
• Champion: Developers find your solution and advocate for company-wide adoption.
• Customer: With developer-focused products, individual developers discover, evaluate, and purchase your product directly.

Your developer tool might attract champion developers at startups where individual engineers drive adoption, while facing consultant developers at enterprises where business roles lead purchasing decisions.

Here’s where traditional marketing funnels break down — these developer roles don’t follow a linear progression through awareness, consideration, and decision stages. A consultant developer may have deep technical knowledge of your product but little to no purchase intent, as they’re not the decision-maker. 

Along the same lines, an implementer developer could be highly engaged with your documentation and tutorials, even if they’ve never seen your marketing website. Meanwhile, a champion developer might skip your carefully crafted nurture sequences entirely and jump directly from first awareness to internal advocacy.

Stack Overflow’s 2024 Developer Survey confirms what the continuum suggests: 62% of developers influence technology purchases. This means developers aren’t just implementers — they’re consultants who evaluate solutions and champions who drive adoption.

The breakdown shows senior executives (99%), engineering managers (87%), and product managers (77%) have the most decision-making power, but individual contributors still matter — only 38% report little or no influence.

But here’s the problem. Evaluations change hands throughout the buying process, so your content might be consumed by a technical champion one week and a business decision-maker the next. Your marketing can’t just translate between audiences — it needs to operate at different depths of technical detail simultaneously.

Identify Your Implementation Depth

Every piece of technical marketing content should know its primary audience, but also be aware of who else it could be speaking to — and convincing. A champion developer researches solutions, which they’ll share with their boss. A product manager reviews your technical capabilities before asking engineers to implement it. A CTO may build a case for engineering leadership. 

Implementation depth means creating content at multiple levels of technical detail. Each audience can access the depth they need. They can also easily find more or less detailed versions of the same information, which they’ll share with their counterparts.

Implementation depth maps to the questions different audiences prioritize during technical evaluations:

• What’s happening? Current problems, workflows, or improvement opportunities
• Why? Business drivers, cost of inaction, and strategic value
• What’s possible? Features, approaches, competitive alternatives, and capability matching
• How? Practical guides, technical instructions, and hands-on enablement
• What’s beyond? Advanced use cases, troubleshooting, scaling challenges, and production scenarios

Each level serves a different audience and corresponds to a distinct decision-making stage. The real power comes from connecting them. Let readers move between levels and collaborate with others whose needs differ.

Cloud platform Twilio is a master of depth transitions. Have a look at their user verification product page.

Business audiences get the context and capabilities they need up front. Technical evaluators can explore ‘how it works’ and ‘view demo’ to understand implementation approaches. Developers ready to build find actual code and quickstart documentation links. 

The page serves as a resource for CTOs researching solutions, developers evaluating technical fit, and implementers building a proof of concept — all from the same starting point, but leading to varying levels of depth.

To bring implementation depths into your own work, identify which of the five questions a piece of existing content primarily answers. Then consider what readers would need at one level higher (a broader context) and one level deeper (more technical detail). Look for opportunities to create those adjacent pieces or add clear bridges to existing content that serves those depths.

Build a Technical Content Strategy Beyond the Marketing Funnel

Adopting a technical product is often a complex journey. Developers play different roles, and non-developers are involved, too. The same pain point can inspire one type of conversation between developers and their managers, but an entirely different one between an executive and their technical teams. 

Content strategies must go beyond traditional funnels to reflect and support how technical decisions are actually made.

Ready to build a content strategy to match this reality? EveryDeveloper brings an outside perspective to help developer tool companies navigate these audience complexities. We identify content gaps across implementation depths and create content architectures that support real technical buying processes. 
If you’re struggling with content that doesn’t convert or audiences that don’t engage, consider a partnership with EveryDeveloper. We’ll help you expand your content strategy across audiences, roles, and implementation depths.

That’s no easy task. Developers are a discerning bunch who quickly detect and skip over content that doesn’t add value to their day-to-day work. If you’re not seeing clear results from your technical content marketing, it might be due to one (or more!) of these mistakes:

1. Making it all about you 
2. Using “high promotion, low value” statements
3. Not getting content into the right hands

Any of these sound familiar? Once we break down each of these common issues, we’ll show you how to achieve better results by adjusting your practices (with a bonus tip at the end!).

Mistake #1: Making It About You

When a developer finds their way to your blog or opens an email, what are they discovering? If the message is all about how great you are — your product, your company, your opinions — there’s no reason for them to stay. 

Developer audiences want solutions for everyday problems and practical guidance so they can learn how trends apply to their work. Too many companies fill their content marketing with promotional statements, competitive FUD, and general navel-gazing that keeps devs from getting to what they’re looking for.

If you want to engage developers, that’s who should be at the center of your content.  

A developer-first mindset highlights real devs solving real problems. You and your products play a supporting role.

Promo-Heavy Content Makes Devs Feel Disrespected

Think about the last time you met someone who monopolized the conversation to talk about themselves and their achievements. You probably felt bored and disengaged very quickly. 

If your content does any of the following, you might be making developers feel you’re that awkward person at the party:

• Highlighting your product or company name everywhere: Developers want to know what problems you can help them solve. If your supposedly educational content feels like advertising, you’ll push them away. 

• Focusing on your company’s kudos: If you intend to share achievements like product awards, customer reviews, or market share, do it only to illustrate why your solution matters. With no practical context, accolades sound like hollow boasting.

• Giving features all the attention: You might be really excited to share a new feature, but it takes more than a spec list to hold people’s attention. Keep the focus on solutions, outcomes, and developers.

• Ignoring that developers have other options: It’s rare that there’s truly only one solution to a problem. Suggesting that there are no alternatives rings false, and it’s a no-no in an industry that embraces flexible ecosystems and open-source tools.

• Tearing down your competition: Developers have choices, and if you fixate on the perceived shortcomings of competitors, you’ll lose their trust. Strong content focuses on what you can do for developers, not what you believe competitors aren’t doing. 

Developer Marketing Should Answer Real Questions

Developers find their way to your content by asking one of two general questions:

• Option 1: “I’ve heard about X company, but I don’t really get what their product does. What could I do with it?”

• Option 2: “I have Y problem. What tools are out there that might help me?”

Successful technical content starts with answering one of these questions. What’s the problem you can solve for developers? How does your product work with other technologies they might be using? How can your product help them rise to the challenge of new tech trends? 

Your answers to these questions should tackle problems developers actually face and in terms they actually use. Instead of sales-speak, your tone should be conversational and relaxed. Even better, incorporate real-life developer conversations (including those from social media and online forums) into your messaging. Your marketing should show that you know how to “speak developer”. 

Remember: If all someone talks about is themselves, who’s listening can become an afterthought. So look outward at developers’ problems and needs — you’ll gain their trust and hold their interest.

Mistake #2: “High Promotion, Low Value” Statements

Developers tend to be smart, analytical, and skeptical. They can sniff out empty claims and needless buzzwords, quickly losing interest in content that doesn’t give due credit to their intelligence.

As fast, easy, and intuitive as you claim your product is, if you don’t supply enough real-life examples and tangible proof, developers will turn around just as fast.

Do You Even Believe Your Own Claims?

Remember that kid in school who used to answer teachers’ questions with too many big words and philosophical-sounding ideas? You never believed they’d done the reading, and neither did the teacher. 

Too much developer content marketing seems to be channeling that kid. And guess what? Developers can tell! If you can’t explain your own product in plain language with concrete examples, relying instead on superlatives and buzzwords, you sound like you’re hiding something.

Some common claims that raise eyebrows and suspicions:

• Do you really have “unlimited scalability”? It’s rare for any technology to handle an ever-increasing workload without eventually needing significant foundational changes. 

• What exactly do you mean by “automation”? Be careful not to oversell your automation features. “Automated troubleshooting” sounds like it happens without human intervention; in reality, only detection is fully automated. People still need to oversee the process and decide what changes to implement. 

• How confident are you that “AI will handle everything”? From coding to QA to deployment, ambitious promises abound as to how AI speeds up software development. Just as with technical content creation, AI can be helpful, but it remains fairly error-prone and best used for specific tasks in the development process.

Cut the Hype

Speak plainly, use clear examples, define key terms, and focus on real-world solutions. If you make big claims, back them up! Don’t be that kid spouting nonsense –- it should be clear you’ve done the work.

You’re speaking to real developers, so the words of other developers are especially valuable. If you have a way to show your product at work in a real application, do it! Use cases make great guest blog posts. Video clips from demos can be reused in written content. For smaller marketing teams, peer-review sites such as G2, PeerSpot, and TrustRadius can bolster the ability to collect testimonials and social proof.

In short, focus on the practical ways your product is unique, and discuss the areas where it makes the biggest difference to devs. And do it in language that cuts the fluff.

Mistake #3: Failing to Put Content In The Right Hands

Once you’ve crafted a content campaign with multiple assets, you can sit back and wait for the engagement to happen, right? 

Seasoned content marketing vets know this is not the case. If no one sees your content, it is a waste of effort. Whether you’re a one-person team or working in a large marketing organization, there are simple things you can do to avoid your content getting lost in the void.

Don’t Get Locked In, Don’t Lock People Out

Do you have a script for releasing new content? Post blog article, send email, post social media blurbs, tag some trending topics, and check it off. 

Sounds like a job well done?

Probably not. 

Different content needs different channels. You wouldn’t (or at least shouldn’t!) handle a thought-leadership article aimed at C-level executives the same as a use case aimed at the open-source community. If you do, there’s a good chance you’re excluding potential customers.

Good content marketing should welcome technical audiences from different backgrounds, whether they’re current customers or not. Unfortunately, some common content marketing practices aren’t welcoming at all:

• Gating is a turnoff: Don’t require people to provide their email address and employer details just to obtain basic information about your product. No one wants emails from sales reps before they’ve even had a chance to read the docs.

• Optimizing for robots isn’t a people-pleaser: People don’t want to read content that’s obviously written to cater to SEO and LLM algorithms. It feels icky, it’s a slog to get through, and half the time, it’s incomplete info. SEO is a starting place, not a destination.

• Talking to everybody means talking to nobody: If you’re trying to cover all your bases with one piece of content, you’ll wind up with something that doesn’t meet anyone’s needs. Target your content at people who need it — in what you say, how you say it, and where you say it. Let key audiences know you’re ready to help them by speaking in terms they’ll appreciate.

Of course, no one has unlimited budget, so how do you lay out the welcome mat without spending too much on content that doesn’t get consumed?

Aim Your Tech Marketing Content Effectively

You have at least one product, possibly more, and likely a range of different service levels and pricing plans. Your consumers will use your product in various ways and possess different levels of expertise, so you need to reach them in different ways. 

The challenge is knowing what the right topics and channels actually are. A few tips can help you sort it out:

• SEO isn’t dead: Search engines are still the most effective way of reaching potential customers who don’t know about your solution. Search engine optimization (SEO) maximizes impact by ensuring your content ranks highly for the questions your audiences are asking.

• SEO isn’t everything: Focusing too much on keywords can result in content with buzzword overload and no clear narrative. Prioritize concepts based on keywords, but develop narratives that speak to developers’ needs and interests.

• Be data-driven: Use digital marketing engagement metrics, such as impressions, click-through rate, shares, and downloads. These shouldn’t be limited to traditional advertising — they can be helpful barometers to shape your content marketing, whether it’s a blog article, newsletter, social media post, or video. Find out what’s working, and do more of it.

• Seek qualitative input: Marketing channels with comment functionality can provide qualitative insight into how your content is landing with different audiences. The combination of quantitative and qualitative data will help you identify your best investments.

• Experiment with channels: Finding the right content distribution channel mix may take a few tries. This may look like testing industry and subject matter forums, partnerships with third-party content distributors, and collaborations with analysts and influencers. 

• Follow your audience: Set up in places where current and potential customers are already gathering and talking, but remember mistake #1 — focus on how you can listen, share, and help others. Don’t forget that your own community page is a great place to start!

Following these guidelines helps you focus your energy on the content that’s most valuable to your audience and gets it positioned where they’ll see it. It’s a little more complex than a single script, but the results will pay off.

Mistake #4: Going It Alone

This mistake isn’t quite like the others — it’s not about what to say or where to share it, but it might be just as important.

One of the most critical ingredients in successful technical content marketing is collaboration. That can take different forms:

• Learn about best practices from industry experts and fellow practitioners through social media and online communities. 
• Get a second (and third, and fourth) opinion on your content by sharing it with preferred customers and trusted peers in other parts of your company before publication.
• Read books like Developer Marketing Does Not Exist and Technical Content Strategy Decoded to get ideas and reflect on your practices. 

Reach out to EveryDeveloper to find a partner who can help you develop and execute on a winning strategy. For example, our LLM Reach Assessment helps developer tool companies understand how their products appear within AI systems like ChatGPT, Claude, and Gemini when developers describe real problems.

Your technical content is meant to be a form of outreach — so it doesn’t make sense to plan and create it in an echo chamber. Seeking other perspectives helps you create work that’s more purposeful and appealing. We’re here to support you along the way — so reach out to us with your questions any time!

Note: Our thanks to Nolan Greene for editorial assistance. 

While this little acronym has emerged in almost every client conversation recently, the hype doesn’t automatically translate to marketing success. In this post, we’ll look at a real example and provide some guidance as you consider whether MCP makes sense as a marketing project.

What is MCP and Why Should Marketers Care?

Marketers of technical products face a constant stream of new acronyms. Over the last two decades, one of those acronyms was “APIs,” which transformed how systems exchange data. Now, large language models (LLMs) like ChatGPT are changing how developers interact with those APIs. The Model Context Protocol (MCP) bridges that gap.

MCP provides LLMs with the context they need to use your API effectively. It’s an additional layer of instructions that help AI models understand not just what your API does, but how and when to use it correctly.

Here’s how it works: developers install an MCP server that connects their LLM tools (like Cursor or Claude Desktop) directly to your API. The server runs locally on their machine and provides the LLM with structured information about your API’s capabilities, authentication, and proper usage patterns.

Developers are already discovering APIs through LLMs—often with mixed results. Without proper context, an AI model might suggest outdated endpoints, incorrect parameters, or unsupported use cases. Alternatively, it might hallucinate instead of accessing accurate data from a structured source, such as your API. MCP facilitates this connection to help a model perform better using your API as input.

Depending on your API and the developers that use it, an MCP server may:

• Expand the use cases your product supports
• Provide developers with new ways to call your API
• Give your company a concrete AI story

There is an expanding number of AI tools of all types. MCP is trending because it bridges AI tools with APIs for both developers and their end users. But these opportunities alone don’t determine whether MCP makes sense for your API.

When MCP Marketing Makes Sense for Your Product

Whether MCP makes sense for your API depends on how customers actually use your product. The key question isn’t whether MCP offers interesting capabilities—it’s whether those capabilities align with your customer behavior and business model. The APIs that benefit most from MCP marketing operate very differently from typical enterprise APIs.

The latest Postman State of the API survey confirms that:

• Most APIs are internal
• Most public APIs support a SaaS

What these stats tell us is that external developers are rarely the audience for modern APIs. It’s engineers inside your organization who use your private APIs to build software for end users. An MCP server may be useful internally, but in this case, it doesn’t need marketing in the traditional sense.

Similarly, a public API that supports a SaaS tends to be used by integrations, likely driven by customer requests. Unless the customers themselves are developers, don’t expect an MCP server to become a significant marketing channel. Think about Slack’s API or Salesforce’s API. Developers use them because their company already uses Slack or Salesforce, and they need to integrate with existing workflows.

This follows our developer marketing continuum: the closer developers are to being your customer, the larger marketing’s role should be.

When we consulted for OpenCage on this very question, our recommendation was to pursue building an MCP server. Here is how I recently used its geocoding MCP server from within my Cursor developer environment:

With the MCP server running on my machine, I instructed Cursor to retrieve latitude and longitude coordinates for every US state capital. The model was able to decipher, thanks to OpenCage’s MCP server, that its geocoding API had the capability to return the data my app needed.

Being technically possible is not the same as being a viable marketing vehicle. Here’s why it made sense for OpenCage to market its API with an MCP server:

• The API is the product, not supporting another product
• 99% or more of their customers use the API
• Authentication is simple, only an API key

As with any development project, there are trade-offs to consider, even if your product is a fit for an MCP server. In OpenCage’s case, the team had available development cycles. There were no competing features, so the MCP project could be prioritized. It’s also a one-time investment: since most MCP servers run locally, there are no ongoing server or maintenance costs.

Though the MCP server was a go, we still had some caveats for OpenCage to consider: namely, not to expect the MCP hype to carry their product to huge gains. We told OpenCage what to watch for and how to quantify progress.

Set Realistic Expectations and Measure Success

You may be impatient for an MCP story, but you need the ending to make sense. To do this, get specific about the problem you’re solving and how you’ll know you’re on the right track. If you know how your MCP server will be used, then you’ll also have a better idea of what it can and cannot deliver for you.

One of the most powerful ways to think about APIs is through use cases. Since we’ve focused on MCP servers to access APIs, it follows that use cases will help here, too. For OpenCage, we recommended that they consider the steps a developer would take that might result in calling its MCP server. Some of the use cases we identified:

• Gather realistic latitude/longitude points to use as testing data
• Batch geocode multiple locations to store as app data
• Build geocoding (reverse or forward) into an application
• Enrich a data source with geographic context

Each of these translates to specific prompting scenarios—a developer asking their AI assistant to “find coordinates for these city names” or “add location data to this CSV file.”

Most of these are ongoing needs, which fit with the expectation that these developers are likely to discover OpenCage through means other than the MCP server. However, it may expand their usage or provide new ways to embed OpenCage further into their stack. Like an SDK, the MCP server doesn’t create demand—it provides a new interface for existing demand. If you treat MCP like an SDK, you should also measure it like one.

OpenCage already has nearly 50 code libraries and SDKs:

The MCP server becomes another way for developers to use OpenCage’s API. Like the Python library serves Python developers and the JavaScript SDK serves web developers, the MCP server supports a growing number of developers who build with AI assistants.

Similarly, MCP likely fits into your existing methods to engage developers. Look first to those areas for measurement. If you include documentation in your attribution, by all means, track whether MCP and AI-related pages drive signups. But also consider how many ways current developers use your API and how their usage is expanded with new interfaces.

It’s still very early for this MCP trend. Expect to learn and adapt as new tools and use cases are developed. For example, in the short time since first consulting with OpenCage about MCP, updates to the MCP specification have already been made, including changes to how it handles authentication. The future of MCP, like APIs, may be more about enabling less technical audiences to make use of these connections.

Your early experiments with MCP could also plant the seeds for future opportunities. Perhaps a customer asks to implement use cases you hadn’t considered. This feedback could both contribute to the product roadmap, as well as your technical content calendar. Both are good for your marketing in the long run, even if today’s MCP server won’t single-handedly drive developer acquisition.

Integrate MCP into Your Developer Engagement Strategy

If you’re a marketer considering MCP, or tasked with announcing it to a developer community, start with the use cases where MCP makes sense for your API. You’ll be most successful with developers when the API is your primary product interface or supports your developer tool.

Don’t look for MCP to be a marketing breakthrough as much as another engagement method in your ecosystem. Instead of replacing your current developer engagement strategy, It should complement. So measure against realistic outcomes like expanded usage and new integration patterns rather than dramatic acquisition gains.

These strategic decisions about developer marketing channels require understanding your specific API, audience, and business model. We help companies navigate these choices, from evaluating MCP to integrating it into your broader developer engagement strategy. If you’re weighing MCP alongside other developer marketing investments, let’s talk about your specific situation.

It’s not just event recaps. A lot of technical content suffers from low views and unengaged readers. The underlying issue is that much of this content doesn’t attract new technical audiences. Instead, it speaks to those who already know your product well. This post looks at how these mistakes happen, how to better reach developers who don’t know you yet, and even how to fix navel-gazing content like the dreaded event recap.

The Danger of Navel-Gazing Content

Many marketing teams set publication volume goals. It’s with good reason — consistent publishing helps fuel other marketing efforts. It also sends positive signals to readers and search engines alike, but not every blog post sends as strong a signal. 

To meet volume goals, teams can often include less valuable posts in the mix. Posts that neither attract anyone new nor engage those who already know about you. These metric-padding posts are easy to spot:

• Recap of an event the company attended
• Product changes and updates
• Interviews with a community or team member

These posts aren’t all bad; sometimes, they’re written for good reason. And each can be framed to be more successful. But most are navel-gazing disasters simply because they focus inward on your company rather than outward on developer needs — this limits their ability to attract new eyes and ears.

The event recap is a prime example of navel-gazing content. Often posted with a headline like [Company] Attends [Conference], it offers little else in the body of the article: perhaps a list of colleagues who attended, a bit about someone from your company who gave a talk, or a giveaway at your company’s booth. In other words, it’s a lot of your company. It’s so cookie-cutter that most of the text could have been written before the event. And each post is like the last.

Product changelogs suffer from a similar lack of point of view when they’re actually prime opportunities to attract new developers. They usually go out with templated headlines: [Product] Updates: [Month] [Year]. Product managers, marketers, and developer advocates all pat themselves on the back for sharing what’s new. But they’ve missed something more important: showing why it matters.

A changelog page in documentation gets a pass for being bullet points. Not so much when it’s published as a blog post. This kind of content can attract new developers, but you have to frame it with a story of how developers can use these changes. Heck, even your existing audience cares why a product update matters. Tell them, first in the headline, then in each article section.

Even developer experience darling Twilio has made this mistake. The company invests in a regular changelog video to share updates with its community. The blog post companion is a simple categorized list. Its headline hints at the “Content Template Builder” subject, but not why it matters. In the middle of the runtime section are some details about why it’s useful, if you make it that far. The video’s title is slightly better, suggesting it provides “Better RCS and WhatsApp messages.” Ultimately, neither the video nor the blog post will likely attract anyone unfamiliar with Twilio.

You could argue events and changelogs aim at goals other than reaching a new audience.  But what about community interviews? As with the other types, the writers of a community interview are well-meaning, but they often conjure an old Bette Midler quote:

“But enough about me, let’s talk about you… What do you think of me?”

Often told in Q&A format, these interviews suggest their focus even with their formatting. The company’s questions are delivered in bold, followed by the community answers in plain text. And many of the questions ask about the developer’s experience with — you guessed it — the company’s product.

Like all the navel-gazing content in this section, you can reframe the community interview to work better. It can engage the current audience and expand to attract those who haven’t heard of your company. 

But it’s admittedly more work to think about what potential readers care about and frame your event recap, changelog, or interview around those things. Indeed, you might be better off spending that effort on other types of content.

Focus on Developer Problems Instead of Your Developer Product

When you work at a company with a technical product, it’s nearly impossible to see the world as developers do. You’re very aware of your product’s features, benefits, and maybe even quirks. That knowledge clouds your judgment about how developers see you. 

Where you see your product as the obvious solution, developers are still figuring out the problem. The same issues that cause navel-gazing content can inflict similar pain across your content. Get into the head of your developer audience, and you can start to understand their problems.

Developers aren’t looking for your marketing. Their time is precious, often split between coding, meetings, and keeping up with tech trends. When they visit your site or read your content, they’re making a trade: their attention for something useful. If you only offer company news and product hype, that’s a bad deal for them.

What makes the trade worth it? When it comes to content, developers want to:

• Learn new skills they can apply right away
• Solve specific problems blocking their work
• Gain insights that help them make better tech decisions
• Find trustworthy sources that understand their world

Notice how none of these value points start with your product. They all focus on the developer’s goals and challenges. The most successful technical content addresses these needs first, then gently connects to your solution only when relevant.

Technical readers can easily spot promotional content. Yes, you need to promote your product, but do it in a way that builds trust. When your content starts with your product before establishing why it matters to their problem, you’ve already lost their trust.

To create content that developers want, start with their problems, not your product. Follow this problem-first framework:

1. Begin with the developer’s context
2. Explore the technical challenge
3. Demonstrate solutions without pushing your product

You can make natural connections to your product’s unique approach only after you’ve shown you understand where they’re coming from.

For example, Algolia reached thousands of developers by tapping into the problem behind its product. The company’s search product supports autocomplete functionality, but instead of pushing the feature, we recommended a different approach — describing what it would take for developers to build it themselves.

By explaining the architecture developers need to build their own autocomplete, Algolia earned a mention of their product that already implements the feature. This approach struck the right balance between education and promotion. 

The rule of thumb is simple: the more educational value you provide, the more product mentions you’ve earned. 

For introductory or problem-definition content, you might not mention your product at all. For solution-focused content, wait until you’ve thoroughly explained the challenge before introducing your product as one pathway forward.

The beauty of problem-first content is that it serves multiple audiences simultaneously. New visitors discover you through their search for solutions, not your brand name. And they’re naturally more qualified leads because they’re already wrestling with problems your product solves. Meanwhile, existing users want to see how you think about the problem space. A problem-first blog post reinforces their decision to use your product and may reveal new ways to apply it.

This approach can transform your entire content strategy, including those necessary-but-often-overlooked pieces like event recaps and product updates. In fact, with the right framing, you can even reimagine these traditional content types to focus on developer problems first.

How to Maximize Events and Product Releases to Attract Developers

You don’t need to delete those content calendar slots for events and changelogs. Instead, you can transform them into more meaningful content to attract developers. They won’t always fit the problem-first framework, but you can use similar ideas to tap into the developer mindset. Then, reframe the post to balance serving existing users and attracting those who have yet to discover your product.

Remember, seeing the developer perspective from within your company can be challenging. One way to force this shift is to put on your journalist hat. You can make this literal, if you want, and keep a fedora tagged with the classic “press” card above the brim. But really, all you have to do is ask yourself these questions:

1. Why does this matter to someone not already using your product?
2. How does someone currently solve the problems this addresses?
3. What is the story or trend within this potential piece of content?

Developers and journalists alike are good at uncovering ulterior marketing motives. When you proactively ask yourself these questions, one or more of them will point you toward better serving your technical audience.

Your work on that event recap post, for example, starts before the event is over. You and others on your team can attend sessions and look out for trends. Even if you’re tied to booth duty, you can survey everyone who meanders past your part of the expo hall. Your recap is not just a regurgitation of the event, but a journalistic examination of the state of your industry.

You can even put in some legwork in advance. Ambassador scheduled interviews with API experts before a conference and used them to turn in an insightful article with none of the downsides of a typical event recap.

The boring bulleted list of a changelog is also no match for your journalist’s eye. Even if your update is the most requested feature by current users, you can identify why someone new would consider it important. Often, the answer is a downside to how the problem is currently solved. In a product update that may have multiple changes, elevate the strongest story to the headline. Even better, find a throughline within the updates, much like the trends in the event recap.

Try one of these template headlines for your next changelog post:

• Build [Common Use Case] Without [Downside]
• The End of [Technical Limitation] in [Developer Task]
• Prevent [Costly Mistake/Downside] Without Sacrificing [Benefit]
• [Developer Task] Without the [Pain Point]

These help you see the story behind your changelog. When you use them, beware of hyperbole and glossy solutions. When in doubt, tone down the overpromises, but even that beats the generic “Changelog for Version 3.14.”

As for those community and team interviews, you can probably guess the recommended approach. Treat that content type like a journalist. Find the story and explain it. You may not need the Q&A format; instead, you can tell the story you discover from the answers. Use subheadings to call out the individual’s point of view. Then, take the best of what they have to say and put it in block quotes.

Even if you keep the Q&A format, you’ll find your questions improve when you foreground the audience, not your product: less “what do you think of me?” and more “why does this matter to you?”

Stop Writing for Yourself, Start Writing for Developers

There’s always room for content that speaks to your existing audience and reminds them about the work you’re doing for them. 

But your marketing should focus on reaching those not yet familiar with your product or community. You need to understand their problems and mindset, so you can attract them in the first place. The good news is that these same things should appeal to your existing audience. They’ll confirm their decision to use your product and participate in your community. 

Take some practical steps to bring this approach into your content:

• Attend your next event with a journalist mindset
• Use the problem-first framework on a changelog post 
• Find a new angle on an old Q&A post and republish it
• Build the dev mindset into your content strategy

Compare the results of these approaches to your old way. Whether you choose pageviews, reading time, or signups as a metric, you’ll see better results.

That event recap post with 12 views? It’s in the past.

Need a partner to help you reach more developers and build trust in your solution? EveryDeveloper brings an outside perspective to help you implement the problem-first framework.

A key moment of planning is whether to develop a solution in-house or integrate a pre-packaged product. That’s led to the “build vs buy” guide, which is popular with marketers, but not necessarily developers. Most build vs buy content is a sales pitch for your product, which rarely matches the developer point of view.

When your aim is to promote your product, your biggest competitor is likely developers constructing an alternative themselves. In fact, they may begin their research thinking that’s the only option. 

Consider Drew, a senior developer in research mode. In addition to feature requirements for a new project, they have industry compliance needs and some enterprise expectations. Your sales team would love to get Drew on their line, but first, you need to get their attention. And gain their trust.

Let’s take a look at the common issues Drew and other developers face when they find your build vs buy guide. Then let’s see how you can ensure your approach avoids the mistakes, so developers can solve their problem and maybe even trust you to do it for them.

Devs Already Know How This Story Ends

Very few projects are completely brand new, and there’s an abundance of existing research to review. Why not try to learn from fellow devs? All Drew has to do first is wade through marketing fluff that pretends to be educational.

The first site Drew finds seems promising. The company uses the right words, and Drew’s skepticism starts to fade. But then, they hit a form asking for way too much information. Full name, job title, “work email,” and… phone number?! Drew reluctantly fills out the form using a burner Gmail account, leaving optional fields blank.

Once fading, that skepticism is now running high. All to receive a “build vs buy” PDF that could have been a webpage. This no longer looks like educational material — it looks like marketing.

Drew’s experience is fictitious, but it could easily be this gated Auth0 page. Though the company has a great history with developers, they’ve gone a little more enterprise under Okta’s ownership. 

Even calling this a “whitepaper” might give developers some pause. The PDF on the other side is neither academic nor deeply technical. It’s a biased argument for buying what the company is selling. Not much “versus” in play here, as they start from the assumption that you want to “move from DIY.”

A better approach would acknowledge that both building and buying have legitimate use cases. Companies could provide transparent analysis without gating content, presenting the full range of considerations for both options.

In software engineering, the answer is always “it depends.” Yet, the typical journey of a build vs buy guide is predictable because the conclusion has been predetermined by the company that wrote it.

For your build vs buy guide to create trust and reduce skepticism with a technical audience, try this:

• Ditch the bias: Present a balanced analysis that respects both build and buy options.
• Be honest about your angle: Don’t try to disguise your sales and marketing as education.
• Avoid gating content: Make educational content freely accessible without forms.

When your guide’s conclusion is skewed towards your product from the start, you’re not educating developers — you’re just making them navigate an obstacle course to reach your sales pitch.

Back to Drew’s research, they quickly confirm there’s little to learn from this first guide. They start to wonder when their phone will ring and how many times they’ll need to click “unsubscribe” before resorting to spam reports. Meanwhile, they’ll move on to the next level of research and hope they find a guide that presents a real comparison.

Devs Want You to Take the Build Option Seriously

Drew loves building. Software engineering is about crafting solutions to complex problems, seeing edge cases in advance, and refactoring around the issues you missed. The reality is that when you buy a solution, you miss all of that fun.

Of course, there are often good reasons to build. In Drew’s case, they have compliance realities to overcome. Luckily, their team has the expertise and a track record of delivering. Most build vs buy content glosses over the build part to focus on the sales pitch for buying. It disregards the team’s talent and presents inflated cost figures, with limited technical details.

Build vs. buy guides miss a basic truth — developers love to create solutions. Building isn’t just about features. It’s about craft, learning, and making something that fits the organization’s exact needs. When guides warn against building with big cost estimates, they attack more than a choice. They dismiss what makes developers who they are.

The choice to build isn’t just about money, either. Teams ask if a project helps them learn new skills. They wonder if it cuts risky dependencies. They value control over key systems. Not everything is dollars and development hours. Average build vs buy guides ignore real non-financial factors in build decisions. As a result, most misunderstand developer motivations.

Even those beloved by developers can go astray. Twilio bought ads on billboards that only say, “Ask Your Developer.” The company is well known for its developer focus. At a glance, you’d think Twilio’s build vs buy guide checks the technical boxes. The very first section is titled “Hosting your own solution.” 

But let’s take a closer look at what they included.

There are four short subsections and one architecture diagram. It’s a fine overview, but it doesn’t take the build option very seriously. After cursory coverage, they go deep on exactly how to use Twilio’s product. While volume isn’t everything, these stats still tell a tale.

A better approach would respect developers enough to actually explore building. Companies should share architectural insights, implementation challenges, and solution patterns — not just marketing talking points. When you take building seriously, you show developers you respect their technical judgment.

The most trustworthy guides demonstrate real engineering empathy. You want to provide the technical details to fully evaluate what it would take to build. Developers will remember who treats them as technical equals and who only sees them as potential customers.

For your build vs buy guide to earn developer trust, try this:

• Offer a balanced view: Give equal technical depth to both paths, not just the “buy” option.
• Get hands-on: Show real code for the tough parts of the “build” path.
• Share your resources: Provide tools for builders, even if they don’t buy now.

When your build vs buy guide treats building as a serious option, you show you understand developers. You’ll earn the trust they’ll need to consider buying.

At this point, Drew has found a few guides that actually address building seriously. But even these more technical comparisons rarely discuss limitations. To make a decision, Drew needs to understand the genuine pros and cons of each option, not just the sales pitch.

Devs Want You to Share the Real Trade-offs

During research, Drew spots a pattern — vendors show their products as perfect. But it’s a different story in developer forums. Other devs complain about issues the companies never mention. The “drop-in solution” now seems to need custom code everywhere. To Drew, it feels like these companies are highlighting benefits while hiding limitations.

This isn’t just Drew’s problem. Developers everywhere face the frustration of discovering problems only after committing to a solution. What looks great in a demo often falls short when implemented in complex, real-world systems. Developers want the honest trade-offs that their peers might share over coffee at a technical conference.

When developers discover these hidden limitations on their own, it destroys trust. Every technical solution has trade-offs beyond price. Your APIs will have latency. Your plugin ecosystem can’t match a custom-built system. Yet most guides pretend these limitations don’t exist. Why?

This guide from Qrvey shows exactly what developers find frustrating. The table of contents dedicates an entire section to “Drawbacks of Building an Analytics Solution,” but has no section about buying drawbacks. The message is clear — building has problems, buying doesn’t.

Developers immediately notice this one-sided analysis. With phrases like “building isn’t all rainbows and unicorns,” the anti-build bias is obvious. What could have been educational content instead reveals itself as just another sales pitch in disguise.

A better approach would admit that every solution has limits. Be upfront about them. Show where your product struggles, what integration issues might arise, and when your tool might not be the best fit.

Honest guides build trust by preparing developers for the real work ahead. Share common workarounds and set clear expectations about performance. When developers hit limits, they’ll be ready, not shocked. This turns potential deal-breakers into known challenges they can manage.

For your build vs buy guide to present trade-offs honestly, try this:

• When are they better off building? Identify specific use cases where your product isn’t the ideal choice.
• Where does your product not fit? Share the environmental or technological limitations of your product.
• When does your product stop being out-of-the-box? Show what customization is required beyond the “happy path” demos.

Developers will find your product’s weaknesses anyway. When you point them out first, you build trust that leads to long-term relationships.

Back to Drew’s search for honest information. After seeing too many one-sided guides, they check developer forums for real experiences. There, Drew finds complaints but also praise for a few companies with unusually transparent docs. With new hope, Drew clicks a link to a guide that might finally understand different developer needs.

Devs Think You Should Consider EveryDeveloper

Drew finally finds a build vs buy guide that feels different. This one respects developers’ diverse needs. It shows options for teams of all sizes and different tech stacks. It even admits when building makes more sense than buying. For the first time, Drew feels respected instead of targeted by sales tactics.

Developers like Drew need resources that acknowledge their expertise and provide honest guidance. That’s why EveryDeveloper helps companies see their products from a developer’s perspective, then creates technical content that presents balanced views and acknowledges real trade-offs. Our approach builds trust first, knowing that’s what truly drives developer decisions.

Ready to build developer trust with your technical content? See how you can partner with EveryDeveloper to help your company connect authentically with technical audiences.

Each day, millions of engineers, developers, and other software builders like Alex awaken to issue trackers, bug reports, code reviews, and feature requests. There are plenty of problems to solve. How a dev tool, API, or development environment works should not be one of them.

Unnecessary friction is a key indicator of insufficient documentation. Sometimes, the friction comes from business actions. Often, it’s from technical inaction. If documentation gets any attention, it’s the bare minimum. At best, it describes the functionality of a tool — all about “what” it is and none of the “why” or “how.”

Robust documentation goes beyond reference docs to include use cases, tutorials, sample code, and even technical thought leadership that makes sense of where a tool sits within a developer’s workflow. In contrast to docs focused on function, robust documentation is all about context.

When Alex goes to an escape room, they collect disparate pieces of functional documentation. Connecting the dots is part of the fun.

When Alex uses a new tool, they want the pieces already collected and ideally presented in the context of the problem they want to solve. Connecting the dots is part of great documentation.

Developers like Alex deserve great documentation because there are still plenty of problems to solve without creating new ones. As we’ll see in the rest of this post, robust documentation is essential for product success, developer adoption, and even your bottom line.

The Cost of Insufficient Documentation

It’s no surprise to see developers complain about documentation. “These docs are terrible” echoes across community Discords, company Slacks, and public forums. 

Surveys consistently highlight this pain point: Postman’s API report shows 39% of developers cite inconsistent documentation as their biggest obstacle. This common frustration risks making poor documentation seem normal and unavoidable. 

But the impact goes beyond annoyed developers. It affects internal engineers, external integrators, support teams, and product managers. From wasted hours of debugging to difficulty showcasing product value, bad documentation has far-reaching and costly consequences. This broader impact demands serious attention and investment in documentation quality.

Companies whose core customers are developers have figured out the importance of developer experience (DX). While that goes beyond documentation, you can’t have great DX without a solid foundation that explains what, why, and how to implement your product.

When the customer is a developer, the value of documentation to the company is extremely clear — you’ll stop growing if developers can’t get going.

On the other hand, if you’re a software company that doesn’t require developers to integrate your tool, documentation is likely seen as one of those nice-to-have pieces of the story. But it’s boggling that so many discount the experience of their own internal team. Yes, engineering is about solving problems, but hopefully not the same ones over and over.

Yet, we’ve been having this internal DX debate for years.

In the last five years, we’ve become only more reliant on API-first development, external integrations, and entirely new toolchains for AI.

Anecdotally, the term “developer experience” has shifted from primarily external to include internal tools. There’s much more focus on automation to set up environments and use consistent approaches to produce engineering work.

Yet, documentation still does not get the attention. That means slower onboarding, difficulty understanding architecture, and a reliance on tribal knowledge. Engineering productivity company Quotient estimates every engineer costs a company $20,000 per month to ramp up. That includes the time of other team members to get them up to speed, which takes three to nine months.

Now consider that API-driven software could be used by other departments or even select external partners. This doesn’t mean a developer becomes your customer, but a developer’s success will now more efficiently get your product used.

Ineffective documentation blocks or slows down any developer who needs to integrate. And we have plenty of examples of bad documentation. From incomplete to completely inaccurate, developers often must guess and check if something works. Even when full functionality is documented, most of these facts miss basic context about why you’d use a tool in the first place. The worst documentation is the one you can’t even find — or maybe doesn’t exist.

The United States Postal Service isn’t exactly known for its technology. There are APIs with PDF downloads that provide factual references. Yet these tables of request tags require significant effort to comprehend. This is a classic “one trick pony” documentation experience. And it’s not the Pony Express.

The success of any project and how quickly it’s completed flows through to its eventual users. If your tool is internal, that could impact every engineer — and anyone needing to use the software the engineer builds. Any platform you build will further amplify the need for developer success.

We should all want to remove unnecessary friction from developers, regardless of where they work. It’s not just the right thing to do, it also saves you real costs. Friction impacts developers, their fellow engineers, support teams, product managers, and your company’s bottom line. 

What do you think? Are those big enough reasons to fix it?

The Benefits of Robust Documentation

The effects of insufficient documentation reach far beyond the developer. The good news is that the impact of robust documentation will also be felt by more than that deserving dev. 

When you invest in documentation, you aren’t just writing manuals. You’re creating a powerful toolkit of tutorials, use cases, code samples, and technical thought leadership. Robust documentation empowers developers, streamlines operations, and enables business success.

Developers may claim to only need reference docs. For public dev tools, this is a reaction to marketing that frequently misses the mark. The reality is that developers will gladly follow contextual content if it speaks to the problems they want to solve:

• Quickstarts to get a basic proof of concept working on their machine
• Tutorials that address real-world scenarios and guide developers to solutions
• Sample code for a practical starting point in common projects or boilerplate.

Devs want to implement quickly and then customize. This combination of guided learning and ready-to-use examples significantly boosts productivity. Developers spend less time deciphering how to use a product or API and more time creating valuable solutions.

Even before developers build, providing a high-level — but still technical — view of a solution is helpful. Use cases round out a developer’s understanding of a product. In the screenshot above, Twilio lays out one common reason for implementing its communication API tools. Yes, it points to tutorials, but it also connects this appointment reminder use case to the real problems that it solves.

While tutorials show how to use a tool, use cases illustrate when and why to apply it. They provide concrete examples that developers can relate to their own projects. It’s also an opportunity to explain the opinions that went into your product. These show you understand the problems and trade-offs a developer might consider in a solution. Share your knowledge to help them make informed decisions about how best to integrate or use a tool.

When your product is technical, robust documentation can help you make your case to customers. However, there are many ways it provides benefits to all software companies:

• Onboard internal engineers
  Much as developer experience has moved beyond external tools, robust documentation impacts internal teams during onboarding and beyond. In-house engineers can use clear tutorials and contextual use cases to quickly guide them into new projects.
• Communicate technical context
  Product teams can provide strategic insights that help engineers understand the bigger picture beyond code. These background details help internal engineers make better technical decisions that align with overall product goals.
• Reduce support burden
  When internal engineers get stuck, they can find someone to ask. This type of repetitive collaboration has real costs, as we discussed in the first section. Your efforts to create robust internal documentation pay off with engineers solving their own problems.
• Enable external integrators
  Partners can significantly boost your success, but supporting them can be demanding. Teams with robust technical documentation are the most prepared for these outside engineers, providing use cases and technical content to quickly support those beyond your organization.
• Prepare for public opportunities
  You may not yet be like Twilio, courting external developers, but documentation makes that future a possibility. When you want to test a platform strategy, you can quickly launch a quality technical product without playing catch-up on docs.

Great public developer companies demonstrate how top-tier docs can become a competitive advantage. By investing in documentation, you aren’t just supporting your current offering — you’re laying the groundwork for faster feature development and more strategic product decisions based on how developers actually use the product.

How to Make Your Documentation a Priority

Robust documentation drives adoption and success. It puts your technical product in the context of the problems it solves. This makes documentation a critical asset for both marketing and product teams. 

In recent years, companies have emphasized product thinking across their technical projects, especially APIs. More than half of respondents (62%) to Postman’s survey point to APIs as revenue drivers, which points to the “as-a-product” approach. When you fully embrace the needs of your technical audience, you can prioritize the right type of documentation. However, it does mean you must promote docs to a core component of your product strategy. Just as you plan for features, plan for documentation.

It’s not just about describing features; it’s about communicating value and guiding users towards success. Whether your product is internal, external, or somewhere between, you can follow these steps to shift your documentation from an afterthought to a strategic priority.

Here are six ways you can make documentation a priority:

1. Conduct a documentation audit

You can’t improve what you can’t see. If you’re like most organizations, you store documentation in various places. For example, when we review public tools documentation, we find multiple quickstarts more often than we find none. Internal docs may sprawl to even more corners. 

👉 Take stock of what you already have before trying to improve it. You’ll avoid piling on to the issue that caused multiple versions in the first place.

2. Talk to your developer audience

You can’t meet needs you don’t know about. Many companies create documentation based on product features rather than user problems. For example, you might thoroughly document every parameter of an API call but miss explaining when and why developers would want to use it in the first place. Teams frequently miss opportunities to address the questions that actually block developer progress. 

👉 You don’t need formal user research to learn from your audience. Developers will tell you what they think, but you do have to ask. You’ll build a foundation for continuous documentation improvement driven by real developer needs.

3. Allocate budget for tools and writers

You can’t expect excellence if you don’t prepare for success. Most companies treat documentation as a secondary responsibility, squeezed into the margins of already full job descriptions. For example, when a product manager is responsible for writing documentation, the task often competes with roadmap planning, customer interviews, and feature specifications. Even with the best intentions, documentation rarely receives the focus and expertise it deserves. 

👉 Intentionally allocate time and resources for documentation, even if not through full-time roles. Turn your documentation into a valuable asset rather than a neglected necessity.

4. Set clear documentation goals

You can’t call it a priority without defined targets. Documentation efforts often lack a clear purpose beyond “make the docs better.” For example, product teams may be very clear about the top three use cases, but these aren’t reflected in robust documentation. A team without focus will miss this gap, so any “improvements” won’t be of high value. 

👉 Establish specific documentation objectives so everyone can agree on your direction. In our example, you might prioritize a documentation page and a tutorial for each use case. You’ll create documentation that supports your product strategy instead of merely describing features.

5. Create a documentation style guide

You can’t scale your efforts unless you agree on patterns. Multiple authors typically create documentation with varying styles and using different terms. For example, one developer’s detailed tutorials might contrast sharply with another’s minimal instructions. Without standards, each new contribution makes your documentation more confusing to navigate. 

👉 Develop a simple style guide for terminology, formatting, code samples, and document structure that everyone can reference. You’ll create documentation that feels cohesive and professional, regardless of how many people contribute to it.

6. Measure your effectiveness

You can’t prove your documentation’s value without tracking its impact. Documentation teams frequently operate solely on assumptions about what’s working. For example, a company might believe its API documentation is comprehensive because it covers all endpoints, yet developers might still struggle to implement basic integrations. These gaps often remain hidden until they seriously impact user retention or satisfaction. 

👉 Track metrics like documentation usage, time-to-integration, feature adoption rates, and support ticket volume. These can demonstrate the tangible business impact of good documentation — and point you toward your next priorities.

If you implement even a couple of these six recommendations, you’ll have a solid foundation for making documentation a true priority in your organization.

However, one pitfall can derail even the most well-intentioned documentation efforts…

BONUS #7. Delay any documentation platform decisions

You can’t make progress if you spend valuable time debating tools. Technical teams frequently fall into the trap of believing the right platform will solve their documentation challenges. For example, we’ve seen platform deliberations become proxy wars for other organizational issues. These discussions often paralyze documentation efforts completely. 

👉 The “perfect” platform is the one you have because it means you can incorporate robust documentation immediately. You’ll deliver value to developers faster while gaining insights that will inform better platform decisions later.

What’s important to remember is that it doesn’t require a massive overhaul to make your documentation a priority. Focus your attention on these key areas — and consider objective, external guidance from a trusted partner.

Get a Docs Partner Who Knows What Developers Want

Developers deserve great documentation, and the steps to provide it are not complicated. You’ll see faster onboarding, greater developer adoption, and improved product success. Robust documentation will reshape your technical product from a set of features into solutions for real problems. 

You can accelerate your progress when you work with a partner who understands your audience. They can provide an objective assessment and a helpful ear as you prioritize your documentation initiatives. EveryDeveloper helps product and marketing teams create documentation that genuinely serves developer needs — turning your docs from a pain point into a competitive advantage. 

Our team combines developer backgrounds with strong communication chops. We’ve seen hundreds of developer portals and can help you identify high-impact improvements through our objective documentation gap process.

Ready to make your documentation a priority? Reach out to EveryDeveloper and schedule a short conversation. Your developers — and your bottom line — will thank you.

The best dev tool and API companies aim to provide a better developer experience with tutorial content. We’ve collected six examples to encourage you to educate and inspire developers!

Provide Code and Context in One Place

A great programming tutorial provides both code and context. You need to know what steps to perform and why they’re important. Stripe engineered an immersive tutorial format for its code samples. It provides code and context in a single page, pulling readers deeper into the experience.

Already frequently mentioned in conversations about the best API documentation, Stripe used its popular two-column approach in a new way with its tutorial. A typical step-by-step guide takes the left column, while code examples are located to the right. More notably, the code emulates an editor with a tabbed interface. Finally, a preview pane shows how the HTML and CSS render.

Developers can click through to explore, though the files are not editable. The real power of this tutorial is clear as you click or scroll through the steps in the left column. The section of code is highlighted on the right side in the appropriate file.

For those who want to make changes, Stripe makes the entire sample available as a download or with a quick click through to VS Code (with the Stripe extension installed). This allows for a more hands-on learning method.

Drip Out Learnings Through Daily Emails

Tutorial innovations don’t need to involve large engineering efforts. If the goal is to help developers layer on additional understanding, that can be achieved by frequent, smaller lessons. That’s the angle Dan Abramov took when he started Just JavaScript.

Though the site now is a complete course on JavaScript’s “mental models,” it started as a simple email sequence. Dan sent an email every day, unpacking another JavaScript concept. Each included an exercise or question, which is answered further down in the email.

But his goal was always something larger. At the time, Dan said as much:

Over time these emails will evolve into an in-depth, interactive, fun, multimedia course that explains these powerful mental models for programming with JavaScript.

However, by starting here, he showed you don’t need to be fancy to provide a good learning experience.

Make the Training into a Game

Would you choose to play a video game or read a textbook? For most developers, they’d grab the controller every time.

Playing Crash Bandicoot and realising how good technical writing and cirriculum is similar to good game design. Note this has nothing to do with gamification, which is a hollow version of game design.— Dan Abramov (@dan_abramov) February 22, 2020

In fact, the long-term plan for Dan Abramov’s JavaScript emails is to become “The Crash Bandicoot of JavaScript courses.” A prime example of a game as developer education is TwilioQuest, the 8-bit-inspired program from Twilio.

Though the company spun it out as a non-Twilio, open source project, it had several iterations inside the company. Originally a web-based experience, TwilioQuest went desktop in 2019 with a cross-platform downloadable game. Developers (and aspiring devs) completed missions while learning about languages, Twilio products, and more.

The game was a key part of road shows and workshops. Here’s how they introduced the 2021 version of the quest, which gives you an idea of how game-like the team made the experience:

https://www.youtube.com/watch?v=oNuB_GYqkR4

It’s no coincidence that innovative tutorial interfaces come from companies like Twilio and Stripe. They are two of the 30 companies with great developer experience. Each company had teams behind these tutorial projects, but that doesn’t mean it’s how you must do it. There are some ready made platforms to help, too.

Provide Everything You Need to Get to First Success

There is much to prepare for developers to try out a technical product successfully. They’ll often need a sample application, dummy data, and an environment to run their test. Only after fulfilling every prerequisite are they ready to learn what your tutorial teaches. That assumes they make it that far and aren’t exhausted.

Red Hat uses Instruqt‘s platform to give devs a complete setup. Their sandbox environments with a framework for sample apps and disposable cloud environments mean developers can focus on Hello World and beyond. Too often, the scaffolding to prepare for coding is the biggest obstacle, and devs never have that aha moment.

You’ll still need to create the tutorial itself when using Instruqt or other sandbox platforms. But the platforms remove the effort needed to streamline the development prerequisites. To get a feel for Instruqt, check out Red Hat’s Interactive Labs. Or read on for other options to host your tutorial inside a tool made for that purpose.

Code Editor with Embedded Screencast

The goal of most tutorials is for developers to follow along with each step, learning as they go. They will retain more of the information if they try it themselves. The team at Scrimba makes that easy with an in-browser code editor that includes embedded audio and video to complete the screencast experience.

In addition to watching an instructor type out code, developers can edit and run the Scrimba tutorial code right in the browser. Anyone can create their own “Scrims,” where you include the files, code, and context that developers will need to finish your tutorial.

Courses with Short, Punchy Screencasts

Some tutorials can be a slog to get through. Whether written or video, you want to provide a sequence of quick wins to encourage developers. JavaScript instruction site egghead provides a great example.

Each lesson is about two minutes long. By necessity, it is incredibly focused on a single topic. These are often part of a larger course, but the egghead style encourages these lessons to work on their own. There’s even a how to egghead site if you want to try your hand at this instruction method.

Build Innovative Tutorials with a Content Partner

Now that you’ve seen how others have pushed the envelope of education, where will you go with your developer tutorials? No matter what, you’ll need to fill your guide with educational developer content. Oh, and you’ll also have to figure out what tutorials you need to help developers reach success.

EveryDeveloper can help you:

• Create memorable, useful tutorials that developers will share with others
• Identify topics with the potential to have an outsized impact
• See your developer experience with a new, objective lens

Your tutorials have the opportunity to build trust with developers and pull them closer. You want to collaborate with a team that has been there. Reach out today.

In fact, that’s why we’ve used the term “developer-focused” ourselves: You can’t focus on multiple audiences at once. If that’s what you’re doing, perhaps you’re elsewhere on the developer marketing continuum.

When companies use the developer-first label, it seems to come down to a few categories and definitions of “first”:

• First marketing audience?
• First users in a company?
• First, as in most important, audience?

We’ll cover each approach with examples from real companies. Hopefully, you’ll also see the lessons you can pull from others’ experiences. And you’ll determine the areas where you can truly put developers first.

Developers as Your First Marketing Audience

Sometimes, companies prioritize developers in the early stages of a product. Using this approach, they may identify a larger market but see developers as the starting point: They’ll focus on developer communities, courting builders to use their product. 

These can be exciting times for developers who find the product. Finally, a tool built for their problems! However, as these products mature, their primary audience often shifts to that “large market” they’ve been eyeing the whole time.

One example is Contentful, which sure looked like a dev tool when it first came to market. Here’s an early version of the Contentful home page.

“All your content, one API” was a promise to a developer. In fact, Contentful helped create and popularize the idea of a headless content management system (CMS). Traditionally, content was stored in the same tool that displayed it, and developers had to grapple with these systems to get their work done. A headless CMS like Contentful made it possible to decouple content storage and delivery.

You can now find all sorts of “headless” tools, which are essentially APIs that let developers interact without needing a user interface. You can customize your frontend without trudging through clunky interactions in the acronym-laden worlds of digital asset management (DAM), customer relationship management (CRM), and more. 

But while modularity might appeal to developers, these tools are often primarily used by other teams. And that’s why Contentful eventually broadened its audience.

Here’s a more recent screenshot of Contentful’s home page.

Not only have they moved beyond the developers, but the first thing Contentful wants you to see is that they cater to several other audiences. Marketers, designers, and content editors all share the stage with devs. And the hero messaging — and that entire home page — is not talking to developers.

Developers were Contentful’s first marketing audience, but Contentful was only briefly developer first.

It’s a natural progression for some companies, even those with a hearty developer focus. My experience at email infrastructure company SendGrid mirrors Contentful’s evolution. We frequently discussed whether SendGrid was a developer company that started with email… or an email company that started with developers. Though developers fueled SendGrid’s early success, solving email deliverability problems for marketers was what eventually ignited the company’s growth.

Now part of Twilio, SendGrid attempts to ride the fence between developers and marketers.

SendGrid still has a great developer story and a powerful API to its deliverability platform. But when you’re paid on volume, your audience is the one who will most increase that volume. For email, that’s marketers.

Indeed, its parent company Twilio — long looked up to as a developer-focused company — has made its own transition to broader audiences. Its suite of “communication APIs” solves problems for more than just developers, even if that’s where they started.

Twilio maintains a good reputation with developers. It includes documentation and other support that devs seek. If your company wants to do right by developers as you broaden your audience, Twilio is still one to look to for inspiration. But first, make sure you aren’t actually another type of “developer first.”

Developers as Your First Users in a Company

In another interpretation, “developer first” means developers are the entry point into organizations. These companies view developers as influential adopters who can introduce their products to larger teams. They create tools that individual developers can easily integrate, then aim for organic growth within that dev’s company. 

Sometimes called “bottom-up” or “land and expand,” this strategy relies on developers to champion the product. Decisionmakers tend to find budget when there’s adoption across their teams. While developers remain important, they’re seen primarily as a bridge to the broader organization.

Take the incident response tool PagerDuty as an example.

This home page message is certainly not written for a developer. It’s typically leadership, maybe not even engineering leadership, who wants to “transform” anything other than data.

Yet, this operational resilience they seek requires that developers use PagerDuty or a similar product or process. Downtime happens, but the best teams quickly learn from it and harden their systems. Yes, individual developers care. At a minimum, they don’t want to wake up and babysit servers. Tools like PagerDuty benefit from usage by an entire team, which is what puts them in this category of developer first.

The opposite approach, often called “top-down,” assumes a product decision is made by leadership and dictated to developers. This makes a lot of sense when the product’s primary user is not the developer. In fact, most API programs and SaaS tools are what I call developer-enabled companies. Sales buys the CRM, for example, and developers implement it.

Top-down tends not to work well for the tools developers use every day. They want to have input or, ideally, use the tools they know will produce the best work. In many cases, they’ll outright refuse. For example, look at this passing comment from a dev on Reddit:

My employer’s IT department is the worst about approving things, so I’m changing jobs because of it.

PagerDuty and dev tools like it still have utility with a few users. For example, you might have an engineering team of five that’s responsible for its own DevOps. They might jointly agree to use a tool together.

Many dev tools are even useful to a single developer, which makes the developer-as-first-user pattern an even more successful approach. Convincing a single developer is easier than an entire team, let alone a company with a top-down approach. However, if there’s not much reason to go beyond “single-player mode,” it’s probably best to focus on a great experience rather than forcing some viral loop.

However, the most useful dev tools will naturally expand within an organization if you have the features to solve larger problems. For example, consider how the API dev tool Postman began as a Chrome extension to easily test API calls. It handled authentication and made the JSON returned from a request pretty.

Over time, it added collections of API requests, testing to make sure the result is as you expect, and accounts to sync your data between machines. While useful for individual developers, this deeper technical work is best shared with a team — and most developers are members of teams.

In this Developer Marketing Stories episode, former Postman marketing leader Kasey Byrne shared the vision that led to the tool’s expansion beyond a solo dev Chrome extension to the platform it is today:

The idea was a platform to program a bunch of tests or even small programs. You can use it to do all of your API work rather than a quick tool to find out whether the API works the way you expected.

Eventually, the Chrome extension was discontinued, and now Postman is available as a desktop app with cloud features. Sharing collections — a useful team feature — is functionality its users expect. Every day, individual developers discover the platform and find utility in it themselves before building alongside the rest of their team.

While developers are an important audience to Postman, its focus is primarily on team collaboration. That makes developers the first, albeit not the only, Postman users in a company. In some ways, these distinctions are related to the stage of a dev tool’s company. Yet, it’s possible to keep focus on developers even when you’re one of the largest developer brands in the world.

Developers as Your Most Important Audience

The third interpretation of “developer first” is perhaps the most literal. In this approach, developers aren’t just the initial audience or a stepping stone to other markets. They’re the primary users and the enduring focus of the product. 

Companies with this mindset build tools specifically for developers, prioritizing their needs above all else. This isn’t about using developers to reach a different audience — it’s about serving developers as the main audience. These companies believe that by solving developers’ problems exceptionally well, they can build a sustainable business. It’s a long-term commitment to the developer community, not just a phase or a strategy.

Two months before filing for IPO (and entering the quiet period), Twilio founder Jeff Lawson published “Your strategy’s last message to developers:”

The problem with building or buying an API as a “strategy” is that strategies change, often rapidly. They shift with new leadership, they shift with corporate priorities, they shift with the breeze. When the latest boardroom talk is about APIs, you get an API strategy. And when attention turns to the next big thing (“Drones!” “Bitcoin!” “VR!”), you get a new “strategy.”

As far as I can tell, it was his last message as CEO of a private company.

Seemingly inspired by Venmo’s API closure, the post discussed why developers don’t trust the whims of API platforms.

Too many companies treat APIs (or developers themselves) as fleeting strategies rather than core business models. Many of us have seen this play out dozens of times: APIs shut down or drastically changed. Dev time wasted. Trust eroded.

Twilio is a very different company now. As mentioned earlier, it has been forced to broaden its audience, yet developers are still a fundamental part of the business, not just a temporary tactic.

Through growth and an acquisition by one of the largest technology companies, GitHub has kept its focus on developers.

The primary message on GitHub’s home page still speaks to developers. They want to build and ship software! Yes, it hints at features that go beyond a developer’s purview (“collaboration” is more likely a leadership concern), but the home page still has code. That’s very developer-centric.

GitHub is a developer tool, but it’s come a long way from simply hosting repositories for a growing open-source version control system. Even in its earliest days, GitHub knew it needed social features to help developers communicate about the code they’re committing. Over time, it’s layered a lot on top of those code repos: issues, pull requests, code reviews, and more. “Enterprise” plans have been part of GitHub for over a decade, but they’re a way to appease devs within the enterprise instead of a clear management strategy.

In 2018, Microsoft acquired GitHub for several billion dollars. How many stories with this plotline end poorly? Most of them. And yet, GitHub continues to be strong with its developer audience.

The GitHub/Microsoft story is not the only positive MegaCorp developer company acquisition. Heroku was still a fairly young product when Salesforce bought it in 2011. And though the cloud hosting platform has experienced some bumps with its dev audience (eliminating the free tier being a big one), they’ve maintained the focus on these builders.

The platform started with its sights on Ruby on Rails. As it expanded to many other languages and frameworks, these technology choices have remained on the home page. In other words, Heroku is not just a broad cloud platform — it’s a collection of very focused entry points to its cloud platform.

That’s not to say Heroku hasn’t attempted to expand its market and audience. The solutions page, for example, shows it wants to speak across an organization.

But a few things to notice here:

1. These are still primarily technical audiences.
2. Developers get the prime, upper-left spot.

To follow in the steps of GitHub and Heroku, it has to make sense for your product and company. But it’s not a foregone conclusion that developers must become less important over time. You can give them the upper-left treatment. And maybe you don’t need to move on to other audiences at all. At a minimum, decide where to put developers first and then ruthlessly maintain your focus on them where it matters.

You Succeed When You Put Developers First

Even if developers aren’t your only audience, there are still ways to prioritize their needs and experiences. By focusing on key areas that matter most to developers, you can create a more engaging and supportive environment. This approach not only benefits developers but can also drive success for your product and company.

Here are five practical ways to put developers first, regardless of your overall audience strategy:

• Show what’s for them. Steer developers toward a space where you can put them first. More than half of the top dev-focused companies have devs in global navigation.
• Share your open source. Developers value open-source contributions. Even if your product itself isn’t open source, make tools and examples available on GitHub.
• Inspire with use cases. Showcase real-world developer solutions. Don’t just tell them how to build — explain why to build.
• Keep robust documentation. As with use cases, great documentation goes beyond the basics. Include all the functionality and context to help developers self-serve.
• Help with the right humans. When developers are ready for help, they’ll ask. But they don’t want to have a long sales call with someone who can’t answer their questions.

“Developer first” may seem like a simple label, but its implementation can vary widely, sometimes in ways that negatively impact the developer audience. While your business strategy will be driven by the market for your technical product — and all the audiences that entails — you can identify the places where developers are the most important audience. In those situations, you can put them first.

Maintaining a genuine commitment to developers in key areas can set your company apart, even as your overall strategy evolves. By implementing the strategies we’ve discussed — from creating developer-friendly spaces on your website to providing robust documentation and support — you can build lasting relationships with the developer community.

When you need a partner for your practice, reach out to EveryDeveloper to discuss how we can help. We’ve worked with developer audiences for companies of all sizes, stages, and definitions of “developer first.” We can save your team valuable time as you navigate a tricky audience.

The real world is a bit messier, isn’t it? For one, many queries are sought with offsite searches, such as Google or ChatGPT. Users may not even click through to your website at all.

But when a developer already knows about your company and makes the effort to visit your online presence, there’s a good chance they’ll find the answers they’re looking for — assuming you’ve thought to put that content somewhere on your site.

Whether your brand gets a handful of clicks or robust activity, there’s always room for improvement. By looking at how developers search for well-known technical companies, we can see the types of information they want from you. Even better, we can create a clearer picture of their problems.

To prepare this post on the pages that developers search, we looked deep into keywords where ten top technical companies rank: DigitalOcean, GitHub, GitLab, Heroku, MongoDB, Netlify, Okta, Postman, Twilio, and Vercel. Then, we removed terms irrelevant to developers, like stocks and CEOs (sorry, finance people).

We found five areas that developers want to explore:

1. 1. Developer experience resources

1. 1. Complementary tools

1. 1. The competition

1. 1. Use cases and tutorials

1. 1. Pricing

Keywords related to these categories appeared in at least five of the ten companies, often more. So let’s discover the keywords developers use, why we think these areas are important, and how you can include the lessons in your work with developers.

Developer Experience Resources: Show Me the Docs

When developers are your product’s primary audience, developer experience (DX) is something everyone should care about. Marketers, product managers, and developer relations teams obsess over every developer interaction with their products. Top of that list is documentation, but as you’ll see, that’s not the complete story.

Developer experience keywords

Dev tool performance is a frequent search topic. All the companies we reviewed had some kind of status page with up/downtime, but what matters to developers is that these pages aren’t buried four clicks deep. A prominent footer link across the website, dashboard, and docs is a trust signal that you value uptime for your dev tool.

What could be more important than uptime? According to the 2024 Stack Overflow survey, an API is the top factor for whether developers will endorse your tool. That may explain why developers also want to find your API. Of the companies we reviewed, only Twilio has an API as the primary product. And yet, all ten have devs looking for their APIs.

Naturally, devs also want to find your API documentation and the docs for your entire product. Like status, they might search for these because sometimes it’s difficult to discover the docs or at least the right documentation (since these companies often have multiple products).

Finally, developers will search for concepts (authentication, security, logs) and additional interfaces to your product (CLI, download). While we’ve considered these as elements of DX, there’s an entire ecosystem around dev tools. You want to ensure your product plays nicely within that ecosystem. You can tap into this interest with content that discusses how other tools integrate with your own.

Inspiration to Reach a Technical Audience

Developers are searching for answers. Make sure they find yours. Subscribe for weekly tips and examples that help you create content developers actually look for—and trust once they land on your site.

Complementary Tools: Help Me Fit You in My Workflow

When we help clients attract more developers to their dev tool, one of the first places we look is the other products their audience uses. 

Let’s say your product analyzes new code checked into repositories. That means engineers who use your product also have a source control system. They likely also run a continuous integration tool. 

Every dev tool will have this cluster of complementary products. We discovered some common categories in our review of these search terms.

Complementary tool keywords

First, artificial intelligence cannot be ignored, as developers search for AI alongside all ten popular products we reviewed. There’s a lot of noise around the topic, but it’s also become part of the developer workflow. We’ve discussed how AI has yet to replace human innovation when it comes to technical content. But these search results show devs want to know its impact, so it’s a good idea to share a story about how they can use AI with your product.

The other terms broadly fall into these categories:

• • Databases

• • Programming languages

• • Cloud infrastructure

Every application needs to store data, so it’s unsurprising that databases show up here. What’s notable is the mix of generic (database, MySQL, PostgreSQL) and specific (Supabase, MongoDB, Elasticsearch) tools.

Programming languages are among our favorite angles for content that attracts a specific developer. If you have a story about how your product integrates with Python, Node.js, or Go, you can reach out to more of those developers and help solve their problems. You’ll also provide a great experience along the way if you have SDKs or other language-specific support.

In addition to programming languages, consider leveling up your product with framework support. Laravel has gained tremendous popularity in the last few years. While it’s the only framework in the search data, other products have succeeded too, especially when we look into more specific tools developers use. Stormpath’s story with frameworks figures prominently in Technical Content Strategy Decoded and is credited with finding a new trajectory for the company eventually acquired by Okta.

Docker, Terraform, and Kubernetes are all ways to provision and run cloud infrastructure. Like frameworks, when you target these open-source tools, you’ll enable developers to use your product within their existing ecosystem. Looking at the keywords, you’ll also find commercial terms, like AWS and Cloudflare; this shows that developers want your product framed around the way they run their applications.

The largest category we found involves complementary tools. And there’s some bias here to the type of dev tools we selected to review. You’ll find these and more when you understand the dev workflow of your product’s potential audience. But let’s not forget the other companies and products that compete for the same developer attention.

The Competition: How Does Your Product Compare?

As much as every marketer wants to present the one and only solution to a developer’s problem, the reality is that options abound. Your job is to understand the pros and cons of available choices and position your product in the best possible light. You can even reach developers while they’re “shopping” with answers to their questions about your competitors.

Competitive product keywords

The competitor comparison with a features chart is a product marketing classic. Developers will likely seek out unbiased versions, but perhaps they’ll give yours a skim. Maybe you can show up as they look for your direct competitors, as well.

There’s also an opportunity for longer versions of these comparisons. Perhaps a roundup of solutions to specific use cases or a deep dive featuring comparisons with developer quotes. 

Just know they’ll take your words with a healthy dose of skepticism. See what you can do to provide something that comes across as more objective and build developer trust through less promotional marketing. 

You can also expand your definition of “competitor.” The biggest competition for dev tools might be a developer building something themselves. That’s one reason we see “open source” among this list of common keywords. 

Developers often look for open-source tools to solve their problems. Provide a reasonable review of open-source alternatives, explain the trade-offs, and highlight when it makes sense to use your product instead. Many will still go the open-source route, but some are sure to give you a try.

Finally, note the infrastructure brands we found in these developer search terms. Since several of the reviewed companies are cloud hosts, it makes sense that AWS and Azure would show up here. These complement many dev tools but appear as competitors here because of the “vs” modifier. Similarly, the flexible Firebase product tends to be compared to cloud tools because of their datastore options. As with complementary keywords, consider your competitive landscape and include the big players in your content.

Use Cases and Tutorials: Share Your Best Practices

Developers love to say: “Just show me the docs.” The problem is docs aren’t enough to communicate why your product matters. And not just that: To whatever extent, everyone wants to be inspired when they’re looking for solutions. A glimpse at the keywords in this section shows how devs might not mind a little guidance.

Use case keywords

Not every one of these searches may be from developer fingers. It’s tough to picture devs asking: “What is GitHub?” But we shouldn’t go the opposite direction, assuming they’re already familiar with our dev tools. There’s way too much for developers to know, and they can’t be experts at everything. In fact, that’s the very reason knowledge sharing is such an important part of the developer experience.

Sometimes, a tutorial is the perfect answer to a developer’s problem. It doesn’t always need to be a video, either. Videos are hard to skim — and skeptical devs won’t be certain your solution will fix their problem until their cursory glance.

Think beyond documentation for use cases and tutorials, and you’ll open up more options to inspire developers with what’s possible. Lean on interactive architecture diagrams, one-pager cheat sheets, and even deep education programs that might lead to certification. Use multiple formats and approaches as you get familiar with the problems your audience wants to solve. 

Though the keywords in this post all mention brands, you can attract even more of the right developers when you present use cases before you mention the product. Yes, help them solve their problems once they’ve found you, but also help them better understand the problems, too. And don’t ever let the problem be: “Where the heck do I find out what this costs?”

Pricing: Can I Afford You?

When we looked at the top dev-focused home pages, we learned that more than 83% include a pricing page. It’s not simply to show how the companies make money. It’s because developers want to know if their organization can afford it. 

In fact, the pricing page is one of the most visited in every SaaS analytics we’ve ever seen. How developers search for it provides insight into how they think about dev tools and what it takes for them to champion a new one in their organization.

Pricing keywords

Normally, I’d grimace at targeting keyword phrases that include “free,” and you’ll see several on this list. There’s a myth that developers won’t buy anything, so you could easily take that lesson here. However, the story may be this: Developers don’t want to pay for your tool until they see that it can help them.

Pricing may seem like a business decision, but it’s so much more than that when it comes to dev tools. It’s a trust builder, but it can also be a trust buster. What developers want is a free trial (or tier) that’s self-serve and clearly explains costs should they want to keep using it. These are numbers 3-5 on our 13 components of great DX. 

Ask any developer about their biggest challenge on costing dev tools, and you’ll have a unanimous answer — getting enterprise pricing without an intensive sales call. The searches here confirm it. Seven of the ten companies we looked at rank for the “enterprise pricing” search, showing how devs are looking for the actual cost of any technical product. They’re browsing forums, asking colleagues, and doing anything to answer that question without talking to someone at your company.

They’re also hedging their bets. The open-source search might seem strange in the pricing section, but we included it here because developers want alternative solutions. Even before they integrate with your product, they think about how hard it would be to leave. Open source could give them an exit.

Build Trust with Every Search Result

Chances are you don’t work at one of the ten dev tool brands we reviewed in this post. But you have a marketing role for a technical product. You don’t just want developers to find it. You want them to try it — and hopefully use it and love it, too!

One good way to make the most of this post is to review each section with your team. Take notes about what you could do better to help developers find the content, context, and other resources they need. Increasingly, those answers don’t come only from search engines. Developers are also asking AI tools how to solve problems and which tools to consider. That means your documentation, tutorials, and product pages influence not only what ranks in search but also what appears in AI-generated responses. 

If you want to understand how your product shows up in those conversations, our LLM Reach Assessment evaluates the visibility of your developer tool within AI systems like ChatGPT, Claude, and Gemini when developers describe real problems.

Inspiration to Reach a Technical Audience

Developers are searching for answers. Make sure they find yours. Subscribe for weekly tips and examples that help you create content developers actually look for—and trust once they land on your site.

That’s the common experience of developers, engineers, architects, and other roles asked to evaluate technical products. Hmito’s experience is one we’ve consistently seen developers voice, often accompanied by the not particularly useful refrain of “developers hate marketing.”

While that may apply for some, the truth is that developers tend to be unresponsive to traditional marketing tactics. If you can understand the distinction, you may find yourself amongst the few marketers who succeed despite the skepticism of a technical audience.

What causes unresponsiveness? In this post, we’ll cover three categories: promising too much and delivering too little, demanding more developers’ attention than they want to give, and not answering their questions. These are the sorts of things that make Hmito and developers like him click away, close tabs, and maybe even write mean things about you in chat — all things you’d like to avoid.

Marketing Frequently Overpromises and Underdelivers

Imagine yourself reviewing a competitor’s comparison table of your product and theirs. Every line or two, you might find yourself shouting at your screen. Pointing at their apples and your oranges. These charts are obviously biased, and your competitor is describing their product in the best possible light.

But you don’t just bring that level of skepticism when it’s your own product that’s the focus — you bring it for every piece of technical marketing you see, and so do developers.

When engaging with technical content, developers look for trade-offs and edge cases. To build faster, for example, what decisions did this company make? What are they doing for me that I might want to do myself? If no frontend experience is required, does that mean I can’t change how the frontend code looks or acts?

Even well-meaning developer messaging can look like an outrageous claim from the skeptic’s standpoint. And it’s a developer’s job to be skeptical! Building good software means watching for areas where computer instructions are open to (mis)interpretation.

Developers are also great at pattern matching. They’ve seen website headlines and polished demos that don’t hold up under the scrutiny of even a glance at the docs. If your promise is too good to be true, it will probably underdeliver. That matches their pattern.

To avoid tripping their radar, avoid hand-wavy or overly flowery messaging, including:

• • Hyperbole: Easiest, fastest, simplest, best

• • Glossy solutions: Highly scalable, zero-config, plug-and-play

• • Non-technical benefits: World-changing, ROI guaranteed, high-velocity

They’ve been burned before. Let’s not bring up those memories.

Sometimes, when we advise companies about developer audiences, they’ll ask how to handle the situation where their product really is the easiest, most scalable, game-changing solution to a dev’s problems.

We tell them to find another way to say it, ideally by framing how well they understand the developer’s pain points; and, perhaps, using toned-down language that can be backed up by data.

Inspiration to Reach a Technical Audience

Skip the gimmicks. Learn how to build real trust with developers through clear messaging, useful content, and technical details that answer their questions. Sign up for weekly strategies that work.

Developers Don’t Want Marketers to Steal their Attention

Any deep work requires focus. I’m writing this post in a state of intense concentration. By getting my thoughts into the right order, I’m hoping they’ll make sense as you read them. Every knowledge worker needs deep work periods. Developers need them more than most.

We’ve known the importance of developer attention for some time now. The Joel Test is 25 years old. Though some of its questions may show their age, #8 calls out the need for “quiet working conditions.” And that’s another way of saying attention — something far too many marketers attempt to steal, which leads to what we all interpret as unresponsiveness. Really, devs are just protecting their focus and attention.

Let’s consider the common metrics marketers use to identify or qualify leads:

• • Fills out a form

• • Downloads an e-book

• • Registers for a webinar

• • Signs up for a trial

Each of these asks for a developer’s attention. However, just because they engage doesn’t mean they’ve given you free rein over all their attention. And this intention disconnect is where developers feel like marketing loses their goodwill.

For example, a developer may be seeking information about a technical problem. They see your e-book or similar content that promises to solve the problem but are greeted by this:

Look at those personal data fields: they’re all angling to misinterpret information-seeking as a lead signal. I’ve seen forms reject Gmail addresses (we want your professional attention), set phone numbers as a compulsory field (to demand synchronous attention), and even request addresses — for digital downloads, so I can only imagine they plan to show up at the developer’s house.

There may be technical reasons for displaying specific form fields. And certainly, a marketer needs personal data to take further steps with qualified leads. But the line for these signals gets drawn far too closely for most developers, so they retreat to guard their attention.

Not every signal is a purchase signal.

Consider the next step companies tend to ask from this technical audience: Join a call, check out a presentation, or watch a demo. These are all asking for even more attention. All the while, it’s very likely that the developer didn’t even get their initial questions answered.

This brings us to the last misstep many technical content marketers make by approaching developers with traditional methods.

Marketing Often Does Not Answer Technical Questions

The overpromises in your marketing disguise what the product actually does. The thirst for metrics is what keeps these developers at arm’s length. So, the previous two sections are ways of keeping developers from the answers they seek.

A developer may find their way to you via product pages, educational resources, or a link from a co-worker. As they navigate, they may check out the home page or follow helpful signals that you can solve their technical problems. The one place they’ll review as soon as possible? Your documentation, of course. It’s the surest way to see if your product can back up its claims.

Devs click on docs because they think they’ll find their answers there — even if it takes some work on their part, wading through references and other minutia. In fact, if you ask them what they want from marketing, they’ll suggest: “Just show me the docs.” That’s the go-to answer because they don’t trust marketing to deliver the truth. It’ll be quicker to figure it out themselves.

“For developers, by developers” is messaging so frequently used that I’d advise against it now. However, the meaning behind it is that these companies want to let developers know that they see them. It suggests that they won’t be overpromised, their time won’t be wasted, and they’ll be able to find their answers. Above all, it shows the company is worthy of developer trust.

Indeed, all of your developer experience should build trust. From the first impression — whether the home page, a product page, or a blog post — through every interaction the developer has with your company, you want to send trust signals. Many traditional marketing approaches will be mistrusted, even if you have good intentions.

Build Trust with Your Technical Marketing

When you examine the indicators that make developers unresponsive to your marketing, it may initially feel restrictive. Especially if you’ve moved from traditional marketing to a more technical audience, it might feel like you’re losing items from your trusty toolbox.

Instead, embrace the constraints. Look for ways to reverse these indicators. Your marketing can build trust rather than erode it.

Implement a list of words and phrases to avoid — like easy, scalable, and high-velocity — and replace them with more factual descriptions. Reconsider what signals make a lead, or question the volume and type of information you must collect. And see if you can guide visitors toward deeper technical details, which can answer their questions and further qualify them when they’re ready.

Yes, it might be more complicated than reaching into your old toolbox. Maybe you need help assembling a new toolbox — one that will get more and better responses, earn developer trust, and maybe even get some fans in the process.

Inspiration to Reach a Technical Audience

Skip the gimmicks. Learn how to build real trust with developers through clear messaging, useful content, and technical details that answer their questions. Sign up for weekly strategies that work.

These are some of the factors that make journalists a skeptical bunch — not to mention that healthy suspicion is part of their job description.

Journalists aren’t here to promote you. What are you doing that’s truly new, different, and impacting people in a concrete way? Marie Williams, Coderella

There’s another audience known for its skepticism: the developers you want to discover, try, and eventually champion your product. That’s why seeing your dev tool like a journalist can help you harden how you talk about it with developers.

While I have a background as both a developer and a journalist, I wanted to round out my advice by reaching out to others — you’ll see quotes from journalists and PR professionals who understand this topic better than I do. Thankfully, they agree on some basic things to help you see your dev tool like a journalist.

The Product Is Not the Highlight

Before I founded this technical content agency, I reported tech news for Wired and was the first editor of the API journal ProgrammableWeb. The majority of press releases I received were navel-gazing feats of unveiled promotion. The best were highly targeted, coverage-aware offers to help me better understand an evolving technology ecosystem. And that’s how journalists will always see your dev tool — as part of a much larger trend and collection of products.

Another thing about journalists is that they probably won’t visit your website thinking about how they’d like to promote your product. They may not visit at all if it’s unrelated to the topics they cover. Dev tools aren’t exactly mainstream.

Don’t expect a niche product to appeal to a broad audience. Justin Pot, freelance journalist (WIRED, LifeHacker)

For example, unless you have a broad angle, your dev tool is unlikely to get coverage in The Verge. The publication claims to cover “companies and products that shape the way we live.” Yes, software powers many of the tools we use daily, but making a direct connection is tough. Your product is more likely to get noticed by journalists with a narrower focus.

At ProgrammableWeb, I was always looking for API news. That’s still a niche topic, but it was even more so then. Though we focused on APIs, it didn’t mean we’d cover each one that made it to market. The pitches we received suggested that most companies thought otherwise. “Our product has an API” was the extent of many emails I deleted.

At one point in my tenure, we were identifying five new APIs per day. Even if we published five posts daily, they couldn’t all be about brand new APIs.

It’s not enough to talk about what your product does or how well it’s built. Think outside the box — you may be delivering a product, but the business outcome could be completely unrelated to development itself. Jennifer Lankford, Lankford Communications

Journalists must filter out what’s most newsworthy. In fact, that’s their job. If you want them to pay attention to your product, help them filter. One of the ways they do this is through interviews — which is something you can do to make sure you know why your product is interesting.

Interview the People Who Know

Marketers for technical products often don’t have engineering backgrounds. Even if you do, you can’t possibly know the intricacies of the product and the problems it solves as well as those who built it.

Similarly, journalists can’t be experts, even when their beat is highly technical. That’s where they use interviews to unravel what matters. Sometimes, that’s difficult to find on a modern dev tool website.

We hear a lot about the developer experience. The journalist experience needs attention, too. Find ways to break down the barriers between the journalist and the developers who can provide the journalist with explanation and analysis. Alex Williams, The New Stack

You may bristle at the idea of connecting a journalist to your top engineers. What will they say? First, you can take on the role of journalist yourself. Your reporting efforts won’t be in the newspaper — they’ll be on your website, blog posts, and other materials.

Make sure you cover both features and benefits in a way that understands the developer point of view. Interviews with your product and engineering teams are one way to gain that point of view.

Obviously, that’s still a biased set of interviews. You don’t have to talk to competitors like a real journalist would, but you should talk to someone familiar with other options — the developers themselves. Yes, you’ve heard that customer interviews are essential. If you already have a folder full of videos, dig into them. But also try a few on your own. Just make sure you discuss the problems, not your product.

Journalists want to keep their readers informed about what’s happening in the world and how it affects them. Journalists want to write impactful stories, not puff pieces. Marie Williams

You might appreciate a “rah-rah” article that only praises your product. Developers will see it and quickly move on to something more trustworthy. They’ll see your content the same way, so you want to follow the most crucial credo of journalism: Find the story.

Find the Story, Obviously

Long before Nora Ephron wrote popular romantic comedies, she was a journalism student at Beverly Hills High School. One story made a huge difference in her career. Much later, it made a difference in my life, as well.

Ephron’s teacher, Mr. Simms, grabbed chalk and wrote six words on the blackboard: “Who? What? Where? Why? When? How?” He explained that the first line of every news story must contain these facts. Then, he went on to tell them some facts for their news story.

The school’s teachers would travel the following Thursday to Sacramento for a colloquium on new teaching methods. Ephron and her fellow students diligently wrote out these facts on their typewriters (this would have been the late 1950s). Everyone had some version of the same lede (or lead), the first line of a newspaper article.

Mr. Simms collected them all, read each aloud… and threw them in the trash!

“The lead to this story,” he said, “is: There will be no school Thursday!”

If you watch Ephron tell it, it’s clear this was a powerful moment for her. She realized journalism is about finding the point — understanding why something matters. While at the helm of ProgrammableWeb, my team and I sought to figure out what mattered in API news. But I always felt like tech companies could have shouldered some of that burden. Here I was, doing a Mr. Simms, throwing their work in the trash.

You might be very proud of a redesign (or whatever is new), but in what specific ways does it help people do stuff better? What does it do now that it didn’t do before? Justin Pot

To see your dev tool like a journalist, you must identify what matters. What use cases does it solve? What dev trends does it follow — or disrupt? You need to find and tell the story in everything you do.

At developer events, speakers may tell you it’s only necessary to provide the factual details. Indeed, “Just give me the docs” is a familiar developer refrain. However, that’s often a reaction to getting too many glossy stories. You’ll build developer trust when you find and tell the unvarnished journalist story. You’ll inspire them to go to the docs with purpose, not to try to figure out why your product matters.

Skipping building a strong messaging framework is the biggest mistake a dev tool company can make. Find that big ‘ah hah’ message that makes your dev tool a no-brainer to buy — for the CTO, but for the CFO or CRO, as well. Jennifer Lankford

As it turns out, the story matters to more than developers. But if you can nail it for them, you’ll have something that matters across your customer audiences. The story does not come by shining a big spotlight on your product. It doesn’t emerge from a shiny pitch. It takes interviews, research, and uncovering the reality where your product lives.

Connect with Outside Experts

To write this article, I knew I needed to get feedback from people with more recent journalism experience. That’s why I reached out to PR professionals and current tech journalists. I crafted my “story” around their observations from years in the industry, along with my own experiences. You can similarly use outside experts to fill knowledge or bias gaps.

Or, work that expertise gathering into your engineering workflow:

Make it a requirement for developers to narrate their work and post in public documentation via micro posts or the company blog. Alex Williams

However you identify and disseminate the objective story of your dev tool, an outside expert can help. For example, they might interview your engineers or translate technical narration into something that fits your messaging framework.

If you aren’t yet aware, EveryDeveloper supports API and dev tool companies to better tell their stories in a way that resonates with your technical audience. See how we can improve the way you present your dev tool. That way, it’s ready for journalists, developers, and anyone who cares about the problems you solve.

This is called the predictive text game, and the outcomes are sometimes silly, often gibberish, and occasionally profound. You may have seen these prompts posted on social media. Sharing the outrageous results with friends can be a fun diversion. But nobody mistakes it for serious craft.

And yet, it’s not that different from the functionality of today’s AI tools.

Generative AI from Google, OpenAI, and others relies on large language models (LLMs) trained on a massive subset of the internet. This incredible resource for context provides much better predictions than texting on your Apple or Android phone. However, the central method is very similar: find the most likely next word based on the information available.

In technical writing, you may be tempted to think the right prompts will return the compelling marketing content you’re looking for. But what you’ll likely receive is an average of everyone else’s existing content. You’ll experience the Curse of the Generic, a plague that existed in technical content long before AI. Your content needs to say something different to attract the right technical audience.

Most technical content needs a point of view. Too often, this is missing—a lack of differentiation is the number one mistake made with technical content marketing.

Whether you use AI or not, you must understand why your product matters to developers and other technical audiences you want to reach. You need to frame your content around the problems your product solves. While AI has its uses, which we’ll get into, it doesn’t yet have the capability of reflecting your unique point of view.

Where Automation Excels With Technical Content

To start, we must acknowledge a potential awkward bias: this article is by a technical content agency. In other posts, we’ve stitched together countless ideas about what makes great documentation, blog posts, and marketing so seamless that developers won’t notice the hemlines. You might expect us to say AI belongs nowhere. However, there are many types of technical content. Not all of them require the same amount of opinion. In fact, some should be “just the facts.”

Take documentation, for example. Developers value accurate, updated, and clear information in docs pages. Even within these technical resources, some pages are more functional, while others are contextual:

• Functional: What’s supported and how it works (reference content)
• Contextual: How it’s used and why it matters (guide content)

There’s already a lot of automation in use for functional documentation. For example, you might generate an API reference from an OpenAPI description. Writing needs to happen here, but the point of view is less important.

Technical writer Tom Johnson shared how AI helped him accelerate his work. He distilled 100+ pages of new product information. He used AI-generated results to create outlines based on his existing documentation templates. He even used AI to help outline and create the first draft of a user guide.

Though most of the work fits into functional content, this last one is contextual. However, it still follows a familiar format—and remember, Johnson is also bringing his documentation experience to all of this effort. He’s supplying a “human overlay” to every AI request, as well as what gets returned.

Perhaps the most impressive automation example is something Johnson describes as “somewhat superhuman.” He used AI to organize hundreds of items stored across a Google Sheet and diagram tree into a single list. Finding structure within unstructured or semi-structured data is an area where machines thrive. Johnson admits his brain would have been “fried” had he tried to take this on himself.

Automation can be a fantastic use of AI for technical content. If there’s a highly templatized process, experiment with how it can help you. These opportunities are far more common in documentation than other types of technical content. Even Johnson concludes that “creative content” is not an area where he’s seeing the same AI impact on his work. And creativity is what you need if you want to reach more developers with technical content.

AI Interactions Are “Generic In, Generic Out”

Once developers have discovered your product, they expect you to explain it. That’s the point of documentation. The sort of marketing content that will attract those developers in the first place is an entirely different beast. You want developers to discover your product through middle-of-the-funnel technical topics that dig into their problems. That means you need a way to stand out from competitors who want to reach the same audience.

We’ve already seen that AI trained on what’s already out there won’t bring unique insights to your technical content. That’s up to you, your product’s positioning, and how well you can incorporate the point of view into your technical content.

Let’s check out an example from APIs (an area we know well). Perhaps you’ve identified GraphQL content that performs well for you.

Your SEO team does some keyword research.

That top keyword looks particularly juicy—it has thousands of monthly searches, big traffic potential, and should be rankable. You greenlight a comprehensive comparison of these two API technologies. Visions of traffic growth dance in your head as you assign this to a freelance writer or attempt a content brief with AI.

As a test, I asked AI to build this outline. It came back with something that’s not bad. Except, it’s exactly what you’d get if you asked AI for this outline. And it’s exactly what your competitors will get when they pursue the same topic.

Go ahead and try for yourself, Prompt Engineers:

Please create an outline for a post that will rank for these keywords: graphql vs rest

It’s missing any hint of perspective because you’ve given it none.

Again, let me emphasize: This is not just an AI problem; it’s a technical content problem.

The Curse of the Generic befalls all who do not take a stand and bring their viewpoint to blog posts, guides, and tutorials. In Technical Content Strategy Decoded, I suggest your job is to translate developer problems to your developer product. To set yourself apart, you must include opinions influenced by your positioning. In other words, apply a human overlay even during the planning process to create something unique.

In the case of our API architecture example, you might:

• Emphasize the flexibility of GraphQL
• Warn developers not to expose their data model
• Stress the importance of API design regardless of architecture

Any of these, or another angle, would impact the outline and eventual content. Even better, it would differentiate your post from all the other approaches to this comparison. You’d avoid the Curse of the Generic and have a much better chance to rank for the search term.

Finally, when developers read a post with your unique insights, they’re much more likely to stick around and sign up for your product.

Avoid Generic Content, with or without AI

The potential of AI is impossible to ignore, even for those with experience creating great, standout content. EveryDeveloper uses it strategically, mostly as part of initial planning. Whenever we use AI, our ideas remain the driver in the process. Identifying what’s unique or important is still primarily a human activity.

By all means, experiment. Whatever you take from AI must be questioned and shaped further. Anything you give it must include original insights if you want anything worthwhile to come out the other side. When it comes to producing impactful technical content—the sort that will attract and convert developers and others—your point of view should be at the forefront.

When you need another set of brains to help identify what’s unique and important—what matters—you can reach out to the humans of EveryDeveloper.

As AI tools become part of how developers discover and evaluate products, it’s worth understanding how your company shows up there, too. Large language models surface tools and documentation based on the content they’ve learned from across the web.

Our LLM Reach Assessment evaluates how visible your developer tool is within AI systems like  ChatGPT, Claude, and Gemini when developers describe real problems. It’s a practical way to see whether your content and positioning are helping those tools recommend you—or quietly overlooking you.

You don’t have to start from scratch with your technical content strategy. Many other dev-focused companies have left clues in achieving their own successes. EveryDeveloper has researched more than 1,000 companies. This post focuses on 30 of the best—including Stripe, GitHub, and Vercel.

The sections below look at how these brands have successfully attracted a technical audience. We explore great examples from landing pages, guides, and blog posts, helping you hone your approach to reach more developers for your technical product.

How 30 Top Dev-Focused Companies Attract a Technical Audience

We previously identified 15 channels for marketing to developers. Around half of these rely on written content, and it’s no surprise. Written content is what ranks on Google—and brings you the traffic you’re looking for.

We collected and analyzed about 5,500 top-ranking pages from 30 of the most admired dev-focused websites using ahrefs data. Let’s dig into how different types of content stack up by looking at monthly traffic per page.

A note before we start: Home pages account for significant traffic for all of these companies. We removed them from this analysis to make it easier to see the patterns that matter.

Even with these big traffic targets out of the equation, other types of landing pages still lead the way. These are important for marketing technical products, even if the content itself is not always technical. However, for many of these companies, landing pages are absolutely still meant for a technical audience.

This high-performing GitHub page purposefully includes a prominent screenshot of code—the company’s product is used primarily by users who write code all day.

Some of the top landing pages include:

• GitHub desktop app (seen above)
• Stripe Payments
• MongoDB Compass
• Elastic Kibana page
• Twilio SMS/MMS explainer

The last of these shows that categorization is not perfect. Twilio’s landing page could easily fall under the ‘Guide’ category. However, even without that last example, ‘Landing Page’ remains a category that shines.

‘Documentation’ rounds out the top categories, another unsurprising one for developers. However, even great documentation is usually very product-focused, which makes it harder to attract developers who don’t already know your product. Documentation likely ranks better for these top 30 companies because they’re known brands that get mentioned in search terms.

Next, while blog content is a hugely impactful channel for most software companies, that impact appears smaller in this research because of how we gathered the data. We included more blog posts than other types, meaning the average traffic per blog post is naturally lower compared to other categories. We’ll look more closely at this later.

It’s also worth noting that some companies excel in a single category, so we removed outliers to avoid overshadowing our other data. That was the case for GitHub, whose user-generated pages overpowered ‘Documentation’ (code repositories) and ‘Landing Pages’ (topics). Similarly, DigitalOcean’s thousands of user-generated tutorials would have eclipsed the analysis of the other 29 companies.

While GitHub and DigitalOcean have carved out their own unique traffic acquisition methods, one strategy that won’t fail most dev-focused companies is developing quality foundational content. In the next section, we’ll explain what that is and how these top companies use it.

Foundational Content Drives More Traffic Than Blog Posts

Landing pages are an important player in converting users, but have some downsides for initial visits, especially with technical audiences. Even with the best intentions, they can appear too salesy to a developer who just stumbled upon your product.

Foundational content, by contrast, eases developers into your company and product, maybe even for the first time. We’re talking the kinds of pieces that identify pain points and seek education over promotion. They’re often incredibly important to the company they serve as the basis for their content strategy. That’s why we refer to this category as foundational content.

In our review of the top pages from the 30 dev-focused companies, foundational content frequently appeared in guide format. A guide differs from a tutorial because it rarely takes a prescriptive step-by-step approach. Instead, it typically chooses a broad topic and aims to create a definitive resource on the subject.

This top-ranking guide brings tens of thousands of visits to GitLab every month. The numbers that ahrefs provides are estimates—and, in our experience, underestimates. The estimates aren’t absolute, but you can compare them to estimates of other pages in the dataset. When you do, they show the power of foundational content.

As an example, blog posts account for just over 50% of the top pages in our research. However, all guides combined receive significantly more traffic than all blog posts while accounting for only 6% of pages.

Some of the top guide pages include:

• What is DevOps? (GitLab, seen above)
• What is a large language model? (Elastic)
• What is OAuth 2.0? (Auth0)
• Understanding SQL vs NoSQL Databases (MongoDB)
• Secure Software Development Lifecycle (SSDLC) (Snyk)

In each of these pieces, the focus is adjacent to the product and audience. Readers interested in DevOps would be interested in GitLab. Similarly, the secure dev cycle piece aligns nicely with Snyk’s security-focused product line-up. Elastic, Auth0, MongoDB, and other companies have good reasons to attract developers to these broad topics.

Guides are the best example of audience-relevant content, which succeeds at attracting and often converting developers.

Consider the share of traffic within the three content-heavy categories:

Guides bring in considerable traffic despite the fact that our research found three documentation pages for every guide. While we didn’t do a complete analysis of branded searches, which include the product name, it’s likely that docs rank for many of these. You can imagine the various versions of “stripe documentation” and similar searches.

As for the blog post category, the approach for guides described above also applies to blog content, albeit with a more narrow focus. In the next section, we look at what kinds of articles work best for these top 30 companies.

Developer Blogs Succeed With Educational Content

Most of the top developer companies have made blog articles a major part of their technical content strategy.

When you think of company blogs, you might imagine a collection of event recaps, product announcements, and glorified changelog entries. While those certainly cropped up on the blogs we reviewed, very few ranked well.

Instead, the biggest hitters among blog articles were those aiming to attract new developers by educating them, inspiring them, and converting them to fans. The typical “what’s new” post cannot compete with one that explains “what matters.” That’s why tutorials receive three times the traffic of product posts, based on the data we collected.

We analyzed the titles for patterns to identify sub-categories for more than 2,000 posts. For example, tutorials tend to use “how to” and “what is” in their titles. This was the second most common category, in addition to the highest average traffic.

Seven of the top 10 blog posts are tutorials:

• GitHub Copilot X: The AI-powered developer experience (GitHub, product)
• SMTP Servers and Sending Emails (SendGrid, tutorial)
• Temporary Phone Number: Set Up in 5 Minutes With Twilio (Twilio, tutorial)
• How SAML Authentication Works (Auth0, tutorial)
• How to Schedule a Text Message (Twilio, tutorial)
• What Is a REST API? Examples, Uses & Challenges (Postman, tutorial)
• Why Is MMS Not Working on Android? 6 Ways to Fix the Problem (Twilio, tutorial)
• Sunsetting Atom (GitHub, product)
• GitHub Copilot is generally available to all developers (GitHub, product)
• URL, URI, URN: What’s the Difference? (Auth0, tutorial)

You’ll notice some commonalities between these top posts and the highest-ranking guides from the previous section. They tend to take a product-agnostic approach to educational topics.

That’s not to say product posts cannot rank. Three of GitHub’s have cracked the top 10, though mostly riding the wave of its popular Copilot product. There’s a lesson in that, by the way—if you’ve created a product with great name recognition, tout it frequently in your blog posts. For the rest of us, we’ll work on gaining some more of that notoriety.

Product posts are easy to spot—they include the product name in the headline, almost without fail.

Listicles, the star of 2010s blogging, still perform surprisingly well. There are almost 400 in the posts we reviewed and they got the second-highest average traffic.

Interestingly, the much-revered Stripe has published very few blog posts. There are about 200 in total, despite the company’s long history. Of those that rank in our research, most have minimal traffic. And almost every single one includes references to the Stripe product. In fact, these mostly rank for branded terms. In short, if a developer has not yet discovered Stripe, it’s unlikely they’ll find it via a blog post.

But the other 29 companies provide plenty to inform your content strategy, including this beast from Postman:

While length isn’t everything, it’s notable that some of the top blog posts are long. Postman’s REST API tutorial weighs in at over 3,000 words. That’s far less than the 180-page Roy Fielding dissertation that created REST, but it’s still 2–3 times the words in a typical blog post.

The adage about writing something as long as it needs to be holds on here. When you take on a big topic, as Postman did with REST, you might have more to say. Above all, you want to find relevant topics that will educate your audience. And that requires knowing them well, with a publication schedule backed by a solid technical content strategy.

Content Strategy Helps You Aim High

We’ve looked at just a few of the lessons we can take away from the successes of these top dev-focused companies. Whether building landing pages, planning deep foundational guides, or writing blog posts that educate, you’ll need a content strategy that resonates with your technical audience.

All 30 of these companies have invested in a content strategy that authentically attracts the right developers, engineers, and architects. They have traded reactive, random topics for proactive, purposeful content that sits adjacent to their product. You can do it, too—and if you’d like support along the way, consider partnering with EveryDeveloper. We can help you create strategic content that ranks.

You may be familiar with the traps to avoid, but where does that leave those of us who want to reach a dev audience? What do developers themselves think gets their attention and makes them give your dev tool the time of day—and, maybe, their company’s money?

Kelsey Hightower asked, and developers responded. There are more than 300 replies to the original message, which we’ve read and categorized.

In their own words, developers want marketers to know these three pieces of advice:

1. 1. Don’t try to impress us, try to help us.

1. 1. Don’t make it feel like marketing.

1. 1. Let us get our hands dirty (with your product).

Marketers are already taking notice:

As a member of the marketing org of a company that sells developer tools, 👀👀👀👀👀👀👀👀 on this thread — Josh Kodroff

And if you want to earn your way into their command lines, inboxes, and hearts, so should you.

Don’t Try to Impress Us, Try to Help Us

Flashy videos, hyped-up sales pitches, and emotion-driven copy might work with consumer audiences. Developers, on the other hand, have learned to filter out the noise. They’re skeptical of bold claims, and for good reason—they’re usually too good to be true. What they do respond to is a genuine focus on solving their pain points and making their lives easier.

When developer Mark Sanborn talks about marketing, you can sense his unease with traditional tactics. Flaunting messages meant to impress often backfire with, at best, closing your browser tab.

Developers want to see clearly how your product works, the problems it solves, and the value it provides. That does not require fluff or gimmicks. Straight talk, transparent messaging, and truly helpful content and resources? Now you’ve got their attention.

If you can showcase your technical expertise while guiding them toward solutions, you’ll not only gain devs’ respect but their enthusiasm as well. Bonus points if you can show how your product can go beyond addressing their pain points, helping them discover new use cases, improve workflows, or build amazing things!

Aim for marketing content that’s hype-less and helpful:

The only thing that works is if you show up high in the search results with enough information there to satisfy me that you can solve the problem I’m searching about. — Brian Alspach

Show the solution without hyping your product in the process. If they buy the concept, they will buy the product. Approach them without overpromising propaganda and be sure to share use cases.

Inspiration to Reach a Technical Audience

Skip the fluff and earn real developer trust. Subscribe for weekly insights on how to market without gimmicks and create experiences that devs respect, remember, and recommend.

Don’t Make It Feel Like Marketing

As you talk to developers, you may notice apparent contradictions. For example, one dev doesn’t want to hear about your dev tool at all. Yet, another dev—or even the same dev—may want a clear, hype-free description of what your product does. Those actually aren’t a contradiction at all. They’re both asking you not to market to them.

Developers inspect everything to see how it works, including your marketing messages. Their pattern of skepticism—which helps them build fault-tolerant software—matches the many signals they’ve seen before. Typical marketing tactics come across as tricky and suspicious, even if they’re well-meaning.

Classic marketing campaigns can also prevent developers from understanding how a technical tool works. That’s not just education in the “help us” sense of the previous section. Your marketing should focus on uncovering use cases and, in some cases, providing transparency to the tech stack.

Consequently, the most successful marketing—the thing that makes a developer attracted to and adopt your product—probably doesn’t look like marketing:

If you understand it’s a marketing strategy used on you, it’s not working on you — Ihar Bury

Some argue that great marketing is marketing that goes unnoticed. That may be true, but most audiences will forgive blatant promotion, or at least tolerate it. Devs will rebel against it.

For example, getting reliable lead form contact information from developers can be tough. They can smell sales pitches three clicks away. Yet, those same developers will cover their laptops in open-source software stickers.

So what’s the difference? The form presents as obvious marketing, while the adhesive freebies feel like supporting the community. When you can suss out the difference, you understand developers.

Let Us Get Our Hands Dirty (With Your Product)

Once you’ve attracted developers to your dev tool, they will want to see it in action—ideally, to try it themselves. Developers want to confirm their use case is possible and that your dev tool fits into their workflow. It’s great to review the documentation (they want that, too), but nothing compares to a first-hand experience. So marketers should avoid putting barriers in the way.

Mitchell Hashimoto, founder of HashiCorp, shares the common boundaries put between developers and a new product.

You may not be able to avoid login screens for SaaS dev tools, but you can find ways to streamline the process. Show how devs can use your dev tool, even if it’s only through command line interactions. Help developers imagine the experience, then let them try it themselves.

Stripe famously lets you test API calls without an account. In its early days, the company would even let you explore the dashboard.

A dashboard is a logged-in experience for most dev tools. Stripe knew devs would be skeptical of signup, so they built their product to make it optional. “Save your account later,” Stripe said, building huge amounts of developer trust.

But you don’t need to go as far as Stripe. You’ll do better than most if you just avoid eroding developer trust:

if I see “Book a demo” or “Talk to Sales” I am out — Yacine Hmito

Developers want to get their hands dirty. That’s how they’ll decide whether to take the next step with your product. Find a way to help them get what they want: a free trial, some hands-on experience, and no contact forms in the way.

Get Developers to Love Your DevTool

The best developer marketing doesn’t feel like marketing at all. Developers aren’t looking for hype—they want help. They want marketing that doesn’t feel like marketing at all. Show that you can solve their specific developer problems, and they’ll not only try your product but also recommend it to others. 

Increasingly, that evaluation starts before they ever visit your website. Developers are asking AI tools how to solve problems and which tools might help. The answers they receive are influenced by the documentation, tutorials, and technical content companies publish across the web. 

If you want to understand how your developer tool appears in those conversations, our LLM Reach Assessment evaluates your product’s visibility within AI systems like ChatGPT, Claude, and Gemini when developers describe real problems. At EveryDeveloper, we specialize in helping companies apply these insights to reach developers authentically. 

Let us help you build the kind of technical content that developers trust—and that AI systems can accurately recommend.

Inspiration to Reach a Technical Audience

Skip the fluff and earn real developer trust. Subscribe for weekly insights on how to market without gimmicks and create experiences that devs respect, remember, and recommend.

So, companies start to throw code samples and technical jargon at a series of unrelated articles on their blog. Perhaps they find some SEO keywords and include those in the titles to gain search traffic. They might even look for a technical content agency or freelance developer writers to help with blog post production. 

What they often lack, though, is clarity on what they want, which prevents them from getting it right when it comes to technical content.

What Kind of Technical Content Do You Want?

Let’s start with the basics. There are many types of technical content, and not all companies or freelancers are adept at developing content that’s right for you.

Here are some types of content for technical products:

• Reference documentation
• Quickstart tutorials
• Use case tutorials
• Language-specific quickstarts
• Sample applications
• Open-source tool roundups
• Technical product comparisons
• Developer inspiration stories
• Engineering case studies
• Technical product pages
• Video product demos
• Livestream coding
• White papers or e-books
• Signature content guides

That list could go on, but there’s one thing you won’t see it feature: blog posts.

Some of these types of content may live on your blog page, but that shouldn’t be your starting point. When you reach out to technical content agencies, the right ones will question what you mean by “blog posts.” Just because your content covers technical topics doesn’t mean you’re producing the technical content you need.

The issue is that many companies focus on form over substance. For example, you may provide a freelancer with a brief for what you envision as a blog post. But they will interpret it as documentation because that’s what the technical content actually is. 

In fact, several content types in the list above belong in documentation. Yet, we frequently see companies publish blog posts that are just glorified docs in blog post form. They’re product-focused, bottom-of-funnel content masquerading in the top-of-funnel.

Another point to be wary of is prioritizing volume over relevance. Ramping up output without the right kind of thought behind it is bound to result in some hits, but you won’t know why. Further, those hits could come at the cost of countless duds.

If you want to hand topics to an agency to produce a host of content, you must be clear about what type of content you want. Unless you’re laser-focused on what you want a technical content agency to produce—and why said content will make a difference to your company—you may not be ready to rev your content engine to high gear. You need to consider the strategy behind your technical content.

What’s Your Technical Content Strategy?

You may be tempted to simply follow the blueprint set by successful tech companies you admire, but this comes with downsides. Content that works for Twilio, Stripe, or Vercel may not fit your product nor speak to your particular audience.

On the other hand, developing your own content strategy comes with many advantages. In addition to uncovering the best publication types for your organization, a solid strategy extends your positioning and explains the opinions upon which your product was built. Further, it can help your entire team—including any technical content agencies you bring on board—understand the translation between developer problems and your product’s solutions.

One of the mistakes we see companies make with content is to publish scattershot topics. Each hopes to land some search keywords, garner attention on social media, or both. And every topic is an island to itself. While the trial-and-error approach can offer a way to fine-tune your messages (usually over a long period), it tends to result in an indiscriminate collection of topics, few of which hit the mark.

We recommend a more targeted direction. Before committing to even a single topic to cover in your tech content, ask yourself (and your team) whether you can discuss it over multiple, diverse pieces. If the answer is “yes,” then what you have is a theme—in our strategy work, we call themes “concepts.” Each of your strategic concepts should contain the potential for many topics. More importantly, each concept should clearly connect to your product.

What does this look like in reality? A one-off topic about the Python casefold() function, for example, may look tempting in keyword research. A compelling concept might be a series of articles covering multiple string manipulation topics, including the Python casefold() function. Finally, you need to compare this Python concept against the other potential concepts to prioritize which makes the most sense for your audience and product.

Whatever method you use to arrive at your content strategy, you need a plan for what to produce and why it matters. Either you already have concepts (or you may call them themes) clearly articulated, or you’ll need a technical content agency to help you. If you do decide to engage with external professionals, a key consideration is how they’ll fit into your workflow.

What’s Your Ideal Content Workflow?

Before you hire a technical content agency, or even a freelancer, identify your ideal content workflow. Which actions would you like to keep internal? Which do you prefer to outsource? Then look for someone who matches what you need. External firms should have a smooth and understandable process for you and your team to sync with. 

In a rough chronological order, this is a list of responsibilities that are inherent to tech content strategy and production:

• Identifying the technical content types you need
• Building a catalog of strategic concepts
• Articulating your company/product opinions
• Researching SEO keywords with developer intent
• Prioritizing topics within each concept
• Outlining topics, including sub-headings to grab the reader’s attention
• Expanding outlines into complete writer briefs
• Coordinating requirements and deadlines with freelance writers
• Circulating written content internally for review
• Chasing writers for edits and additions based on feedback
• Migrating the finalized copy into the content management system

Many technical content agencies don’t offer the foundational work represented by the first half of the above list. This requires you to develop and maintain a deep understanding of your audience and product—and communicate it to them over and over again to get the content you’re looking for.

In other words, there’s a separation between your team and the writers—you must handle strategy, research, and planning in-house, then heave topics, outlines, and briefs over the wall to the agency writers. They’ll follow your instructions and hurl their content back over the wall for your review.

EveryDeveloper believes you should remove the wall.

Not only is the over-the-wall method a lot more work on your likely overstretched team, but you also miss out on valuable, objective expertise from an agency that’s collaborated with a lot of companies. 

Who Can Become a Technical Engagement Partner?

To reach the right technical audience, you need a partner who can help build your content strategy. They will save your team from explaining—and re-explaining—what matters. Plus, you’ll build on their expertise applied to your product, not just your content.

As you look to hire a technical content agency, look for a partner who will help identify strategic content types, expand powerful concepts, and collaborate with your team. This partner will provide an objective, external view. Your strategy will be better and your content will understand how the technical audience sees you—which is different than how you see yourself.

Naturally, as you research these partners, we hope you consider working with EveryDeveloper.

As you choose which developer events to attend or sponsor, you’ll also be looking for a way to stand out. I like this example from Mashery so much that I hopped on a call with one of its creators, Neil Mansilla. 

He walked me through Mashery’s approach to engagement activities at events and how his thinking has progressed over the years. More than 10 years after the API Challenge series (they put it on at several other conferences), he still sees the power of puzzles to engage a developer audience. And I found his ideas compelling enough to share here.

Align Your Objectives With Your Puzzles

Even before Neil set up the API Challenge leaderboard at the particular booth I visited, he knew the idea would deliver on his company’s primary goal of raising brand awareness. While that may seem hand-wavy, getting their name out during this rise of APIs was most important. With a puzzle that collects unique entries, they also had something much more meaningful than “number of shirts shot from a cannon.”

There were three goals for Mashery’s event sponsorship, driven by the API Challenge:

• Make developers aware of Mashery’s API platform
• Show off how easy it is to get started with Mashery APIs
• Provide visibility to Mashery customer APIs

To complete each step of the challenge, developers had to make API calls, inspect the results, and figure out the next step. As part of the rules, Mashery pointed to a list of APIs​​ that would help solve each step. These APIs happened to belong to Mashery’s customers and run on Mashery’s platform.

When we chatted, Neil admitted that Mashery’s definition of event success was more easily attainable than it might be for other companies. As part of the developer relations team, he didn’t need to generate leads from this conference. He couldn’t even expect signups directly from the event, since API management was typically an exec-level purchase. However, he suspects many developers tried out their platform afterward. Developers often champion great products and could put Mashery in the conversation.

Many conference booths give away T-shirts and other branded merchandise. That’s certainly a route to awareness, but will a developer remember you and associate you with anything other than a freebie? Probably not.

Mashery’s API Challenge had all the attraction qualities of swag, with the stickiness that comes with giving developers a fun problem to solve. In addition, the leaderboard grabbed attention and made people want to see their names (ideally, near the top). Attendees stopped to ask about the challenge and participants would return for hints from the Mashery team. And that gave them a chance to point out, for example, that Mashery’s software was driving the breezy API Key process. And it certainly didn’t hurt that Mashery had brand-name APIs for developers to try as they competed.

One way to align your objectives: Connect your challenge to your product without being overtly promotional.

With good conversations and healthy competition going, the API Challenge became a go-to engagement tool for Mashery. Neil was quick to point out that the sophisticated leaderboard and automation came after they’d already proven the concept. If you’d like to engage developers similarly, don’t try to build it all at once.

Start Small and Iterate on Developer Puzzles

The Mashery team used to attend 60 or more conferences annually. Over the years, they ran the API Challenge at many of these events. They had a chance to see developer reactions to the puzzles, make adjustments, and improve the overall infrastructure. The leaderboard, for example, was an entire software application itself! But they didn’t start there and you shouldn’t, either.

All you need to begin is an idea or even a single question. Put that together with simple form software attached to a spreadsheet. That’s enough to be more engaging than the standard conference booth.

If you’re already giving out swag, make your simple puzzle the way to unlock the prize. Mashery gave every entrant in the API Challenge a bottle-opener thumb drive — trust me, these were cool.

Similarly, Keen IO would give away shirts to anyone who used the “Wardrobe Resource” API. Hidden in its documentation was an endpoint that accepted a name, address, and shirt size. Make the right request-which was built atop Keen’s existing data platform—and some swag might arrive in the mail. While the company could use this as a mini-puzzle at conferences, they also left it public as an easter egg. I tried it and it worked (and sorry to say it’s gone from their docs today).

Even though puzzles could be done remotely or even asynchronously, Neil says they work best in finite time and physical space. That’s also good advice for starting small. If it works well, you can always expand it later.

Make your puzzle related to something within your product. Give them a reason to explore to find an answer, but make that first one easy enough that it doesn’t take much searching.

For your initial version, you don’t even have to worry about automated “grading.” Any team member at the booth can look for the person’s name in a spreadsheet of entries and confirm they put the right answer.

One way to start small: Use a simple form to collect puzzle answers, but don’t treat these like leads!

Once you confirm developers are taking an interest, you can iterate and expand your puzzle. Perhaps create more elaborate questions or activities. Or build out the way you collect the answers. Whatever you do, don’t do it alone. At Mashery, successfully engaging developers at events was the definition of a team effort.

Make It a Fun Internal Collaboration

The API Challenge was bigger than a single event and its reach went beyond conference audiences. Everyone I’ve talked to who worked at Mashery still remembers these challenges. More than that, they seem proud of the way their former employer reached technical audiences at events. After talking with Neil, I can see it’s because many of these people were themselves involved in the API Challenge iteration.

While Developer Relations was the team delivering the API Challenge at events, many others at Mashery pitched in with their ideas. Neil would broadly share their goals and examples of existing questions. Other coworkers would chime in with ideas — often diabolical twists to increase the difficulty. 

As you put together your puzzles for developers, it’s a good idea to have different stages to the challenge. The initial ones should be solvable in just a few minutes. You want to provide some early success to maximize developer interest. Then, make the puzzles progressively harder. Neil recommends three levels of difficulty. You can categorize input from other teams as easy, tough, or somewhere in between.

In addition to ideas, you can trial your challenge internally. You can even give the same prizes out and share top results to encourage participation. To my surprise, Mashery varied the API Challenge with each event. While audience overlap is rare, answers could slip out online. Plus, I think the Mashery team enjoyed the iteration process.

Among the teams to consider for input and to test your puzzles:

• Developer Relations: They understand what engages the audience
• Marketing: They know entertainment and can connect to the product
• Engineering: They may be the audience you want to reach
• Support: They talk to customers and know the product well

Keep all the feedback you receive, especially ideas to improve the system. Anything you don’t use for your first conference you can put into practice at the next. 

One way to collaborate: Ask specific teams to try your puzzles and send in their ideas for improvement.

As for Neil, he left Mashery later in 2014 but brought his developer engagement skills to multiple companies in the last decade. Since 2017, he’s worked on developer tools and practices at Atlassian, known for its now-departed Dragon Slayer Quests… and a suite of collaboration tools for software teams. With Neil on the team, you have to wonder what new puzzles await at the next Atlassian event.

Engage Developers with All Your Content

What Mashery did was take the typical conference booth — free T-shirts and sales pitches — and make it something a developer wants to engage with. The truth is that to reach more of the right developers, all your content needs to resonate with them. Technical content is far too often shouting and touting like an overeager carnival barker. 

Instead, you want to connect the developers’ problems to your product with content that teaches and builds trust. This will engage the audience you want to reach.
To start, avoid these super-common technical content mistakes. The first alone could save thousands of hours spinning your wheels on content that’s unlikely to resonate with your audience.