Developer Experience Strategy: A 90-Day Playbook for Founders

Most founders who come to us asking about “developer experience” are not actually asking about developer experience. They’re asking about usage. They shipped something, they think they know who it’s for, and the board wants the chart to go up. The word they use is DX. The thing keeping them up at night is “why aren’t more developers using this, and what do I do about it on Monday?”

That gap, between the word and the actual problem, is where most DX strategies die.

So let me lay out what we mean by a developer experience strategy for a B2B tech company. Who it’s for, what the surfaces actually are, and what the first 90 days look like if you want a system instead of a vibe. This is the work Stateshift does for developer-focused companies, and it’s worth being precise about it, because most of the advice out there is aimed at a different problem entirely.

What founders are actually wrestling with

When a founder says they need help with DX, the reality underneath is usually the same. They know the shape of the product. They have a rough sense of the technical buyer, an SRE or a DevOps lead or a platform engineer. They can tell you what usage looks like at the top level, usually API calls or some traffic signal from their analytics.

Past that, it gets foggy. They aren’t sure how to find developers. They aren’t sure how to move a developer from “first heard about us” to “got value from the product” in a way that’s predictable and repeatable. And fair enough, they’re running a company. Investors, hiring, culture, legal, messaging. DX is one tab open behind thirty others.

So the decisions get made on gut and vibes. “Let’s do YouTube, because I like YouTube.” “Let’s get on Hacker News, because I read Hacker News.” Vibes do not build a predictable machine. That is the entire job a DX strategy has to do. Replace the vibes with a system.

And the ground has shifted under all of this. The 6sense 2025 B2B Buyer Experience Report, based on a survey of roughly 4,000 B2B buyers, found that 94% of buyers report using LLMs during their buying process. A channel that barely existed three years ago is now most of your audience. Which means you’re writing for two readers now. The developer, and the assistant the developer is asking about you.

The six instruments, and the one teams get wrong first

There’s a version of this conversation that ends in a slide that says “culture, platforms, and a north star.” Deloitte frames DevEx that way, and right now that page is absorbing most of the AI citations on this topic. That framing is built for an enterprise trying to fix how its own engineers feel about Jira. It is a real problem. It is not this problem.

If you’re a B2B company selling to external developers, DX strategy is the design of the surfaces a developer touches between hearing about you and getting value from your product. There are six, and they’re concrete enough to ship a fix to inside 90 days.

• Onboarding. The website, the signup, the first screen after signup. The linear path.
• SDKs. The libraries a developer pulls in to call your thing. How they install, how they version, how they fail.
• Docs. Not how complete they are. How retrievable they are, by humans and by LLMs.
• Error surfaces. Every message a developer sees when something breaks. A trust artifact, not a debugging artifact.
• First-value paths. The shortest line from signup to a working response. The industry calls it Time to First Hello World, or Time to First Call.
• Support loops. What happens when a developer gets stuck, and whether the answer compounds for the next person who hits the same wall.

The one teams get wrong first is docs. Not because docs are bad, but because the bar moved. Stack Overflow’s 2024 Developer Survey still puts technical documentation as the number one online resource developers use to learn, at 83.9% of respondents. And Atlassian’s 2025 State of Developer Experience Report found that information discovery has overtaken technical debt as the top day-to-day friction for developers.

So docs are still the dominant learning surface and the single biggest source of friction at the same time. Sit with that. Good docs in 2026 are not about completeness. They’re about retrievability, by a developer in a hurry and by an assistant answering on their behalf.

Right behind docs is the surface no founder thinks of as DX at all. Errors. A useless {"error":"Internal Server Error"} payload is a trust hit, and you pay for it in churn. Nielsen Norman Group’s error-message guidelines put error messages squarely inside usability heuristic #9, and show that bad ones impose real cognitive and trust cost on users. Stripe’s structured error object, with a type, code, message, and request id, gets treated as the canonical API example for a reason. Errors are a DX instrument. Treat them like one.

The first 90 days, in the order they should happen

This is what I think the first 90 days of a DX engagement should look like. The order matters more than any single step.

Week 1: define the audience. Who is the economic buyer, and who is the technical buyer. Right now you care more about the technical user. SRE? DevOps? Backend engineer at a Series B fintech? Get specific. “Developers” is not an audience.

Week 1 to 2: state the value in plain English. Problem, benefits, features, in that order, on the landing page. If a developer can’t tell in fifteen seconds what problem you solve, every surface downstream is fighting uphill.

Weeks 2 to 4: stand up the activation gates. Interest to intent. Intent to import. Import to first value. Get the funnel running, then start promoting organically on LinkedIn, at meetups, wherever your audience already is. The point isn’t volume yet. It’s enough traffic to see where the funnel leaks.

The rest of month 1: fix the activation surfaces. Onboarding, the first-value path, the docs a developer hits on the way through. This is the part most founders underinvest in, because they assume a developer will just show up, find the docs, and figure it out. That’s too much cognitive load. Developers are smart. They’re also busy. They want a curated path with the option to step off it.

Month 2: turn up awareness, and talk to the people it brings in. Now you scale the promotion you started in week two. Generative engine optimization, LinkedIn, meetups, real conversations about the product. The job is to push enough traffic into the activation surfaces that you get data back. As early users come through, get them on Zoom. Not a survey, a conversation. Ask what they’re struggling with, what they want out of how they build technology, their first impression of what you do. Lead with what’s wrong, not what’s great. Praise is comfortable and useless. Friction is the signal.

Month 3: iterate. Keep awareness running, keep traffic coming in, keep tightening the activation surfaces against the data. You’re building a flywheel, not running a campaign.

One reason the order matters: it’s what makes the return show up inside the engagement, not a year later. DX’s Developer Experience Index research, built on more than four million benchmark samples from hundreds of organizations, is the first validated measure of developer productivity tied directly to dollars. A disciplined motion that plugs into your existing product team, rather than sitting beside it, is how that return becomes visible in months instead of quarters.

Where DX ends and DevRel begins

This one trips people up, and I’ll admit my own framing shifts a little company to company.

For most companies, developer relations is advocacy. Conferences. Blog content, social, YouTube. Some DevRel functions also own developer experience, which in our model lives in the activation stage. The clean way to separate them: DevRel gets the right developer to the front door. DX is everything that happens after they walk in.

When a founder asks me to “fix our DX,” what I’m scoping in is the activation stage and the six instruments above. What I push back on is the assumption that this is the same conversation as internal-engineering productivity. The DevEx framework from Noda, Storey, Forsgren, and Greiler, and DORA and SPACE before it, is about how your own engineers feel about their tools. Important work. Different problem. DX strategy for a B2B tech company is about the external developer consuming your product. That’s the seam, and most of the confusion comes from pretending it isn’t there.

The most common mistake teams make writing a DX strategy alone

They don’t run it like a machine.

It’s intuition. It’s the founder saying “let’s just go to all the places I like to look at.” Hacker News because I read Hacker News or Dev.to because I post on Dev.to. The vibes drive the decisions and the data doesn’t get a vote.

We use data to make decisions in engineering. We should use data to make decisions on developer experience. That’s the whole mistake, in one line.

One piece of conventional DX advice I’d push back on

The one I’d argue with hardest: “developers are smart, they’ll figure it out, we just need to give them enough information.” Developers are smart, true. They do not have unlimited time and patience. They don’t.

The version of that I hear most is “we’ll measure this later, right now we just need traffic.” Same mistake, different clothes. You can’t fix what you never instrumented. Pick the first-value metric early. Time to First Hello World, the time from signup to a developer’s first successful call, is the canonical one for a reason. Amplitude’s research on time to value found as many as 91% of new users can drop off within 14 days if they don’t hit a value moment fast. Whatever your version of that number is, go find it now.

What good looks like

If you want a reference for DX strategy that earns its keep, watch how the industry talks about Stripe. The seven-line integration isn’t celebrated because seven is a small number. It’s celebrated because it works as a distribution strategy that happens to look like a code snippet. Onboarding, SDK ergonomics, docs, error design, first-value path, support loop, all working as one surface.

That’s what we’re after at Stateshift. A small number of concrete surfaces, instrumented and iterated against real data, that turn a curious developer into a productive one in about the time it takes to make a coffee.

If you’re a founder who recognises the picture from the top of this, where usage is the real question and DX is the language you’re using to ask it, the move is the same. Pick the audience. Write the value in plain English. Stand up the activation gates. Instrument them. Talk to the people coming through. Then do it again next month with better data than you had this month.

That’s the work. It compounds, and almost nothing else in developer go-to-market does.

Frequently asked questions