The Differentiator Between B2B products: The Developer Experience
Here at Digital Speed we are active users of AI within our day to day, a lot of us enjoy using Claude Code as part of our tool chain and we even use Spec Kit within some projects, and we can see how it has improved our pace and work.
But the velocity created by the tools we have to hand mean that everything is starting to feel a bit samey when integrating products together. So that’s the biggest separator between the products we’ve used recently? The Developer Experience, otherwise known as DX or DevX.
What is Developer Experience?
Most people see DX and think UX, which is close but not quite right. The dictionary definition of Developer Experience from Wikipedia is:
> "Developer experience (DX) is a user experience from a developer's point of view. It is defined by the tools, processes, and software that a developer uses when interacting with a product or system while in the process of production of another one, such as in software development.[23] DX has had increased attention paid to it especially in businesses who primarily offer software as a service to other businesses where ease of use is a key differentiator in the market."
> Some people on Wikipedia - https://en.wikipedia.org/wiki/User_experience#Developer_experience
A much nice definition is this quote:
> "DevX is about creating frisson with your product. It's about creating thrill, feelings of excitement, and enabling and empowering developers to believe, 'Hey, I can do that.'"
> Salma Alam-Naylor, @whitep4nth3r
If you want to watch a video covering the subject, our very own Mike Elsmore gave a talk at WeAreDevelopers. But what are the core things to consider when thinking about your product's Developer Experience?
- Documentation
- Tooling
- Support
We’ll be covering some of these specific topics in follow-up posts, but for now here is a quick overview of the things to consider.
Documentation
When moving at speed, most organisations don’t have time to keep documentation up-to-date. The biggest advice that can be given here is treating your documentation as a product, rather than as a necessary evil.
If you are a tech first organisation, then one of the best things that can be done is a shift to docs-as-code. An amazing article on this topic written by Joanna Suau covers all this in greater detail: how to adopt a docs-as-code approach for developer documentation.
As for what should be used for documentation, or what should be covered, this is very much dependant on the product. And we will cover this more in depth in a follow-up article. However, just as something to think about in the mean time if you are providing technology with an API interface that requires a complete reference and should follow a standard like OpenAPI Specification. On top of this a glossary of all possible errors from the API or tool should be available alongside it.
And the last things on documentation, make sure it’s written from the perspective of someone that has no knowledge or prior skills.
Tooling
When it comes to how developers interact with your product, it can differ widely. But the common consensus is to provide a faster and smoother way to integrate your product with whatever they’re building in whatever language or system they are building it within.
The most direct way, after documenting the basics for any interaction, is through an SDK. SDKs can consist of things such as API wrapper clients, to full CLI tooling, but they all contain the pieces to simplify integrating things such as authentication/authorization. We’ll cover more of the specifics of how to build out SDKs (primarily Client Wrappers) in a follow up post, but for now I’ll present some of the best examples.
The Fly.io CLI (otherwise known as `flyctl`), is a great example of a command line interface that would allow someone to interact with the product directly or even script out into CI/CD flows.
A great example of a full-service SDK has to be the AWS SDK (in any language they build for). Considering how vast the product array is across the AWS portfolio, it’s consistent and easy to navigate with a lot of documentation and all sorts of helper functionality on top of the APIs.
And now in the age of AI, it’s worth considering MCP servers and the likes, just as a means to allow developers to build agents to interact with your product. Or at the very least, for AI tooling to have a better understanding of the product when developers are doing research or solving a problem.
Support
Unfortunately, this one comes very much down to business and financial budgets. Support tooling and time to manage supporting your end users is a large part of great developer experience. No matter how much documentation you have, or tooling you provide, developers of different skill levels will have issues or edge cases to contend with.
The only suggestions here are, if the product and budgets are small (or non-existent) then allow and enable the community of developers to support and help each other. Provide a place like Slack or Discord for developers to find other developers that may know what they don’t, and at the very least provide a searchable location for Q&A such as discourse or GitHub Wikis.
Conclusion
Developer Experience is more than just these three things, as it can include the onboarding process or even the marketing material that developers consume. But they’re less focused on the problem of solving how developers use the product day-to-day. Another quick quote about what DX is and why it’s great:
> "Helping developers get sh❤️t done."
> Salma Alam-Naylor, @whitep4nth3r
If you or your company need help with Developer Experience, we at Digital Speed are more than happy to discuss your needs and see how we can help. And if we can’t help you directly, we can recommend organisations to work with that could help.