Five ways to improve developer experience in web3
The critical role of DevX in web3
TL;DR
Developer experience (DevX) is crucial in web3. A strong developer ecosystem drives transaction volume, TVL, and revenue.
Great DevX is embedded across the organisation. The House of DevX covers DevX strategy, developer onboarding, developer tooling, developer relations, and internal DevX operating model.
Five ways to improve DevX in web3:
Create a North Star Metric for DevX
Focus on the Developer Moments of Truth (DMOT)
Structure documentation around key use cases
Over-engineer the unhappy path
Leverage the community
Why DevX is crucial for web3
In many ways, a great DevX is more important in web3 than in web2. When we talk about DevX, we are not only talking about internal developer productivity. We are talking about the experience that an external developer has when interacting and using your platform or product. Great DevX attracts more developers to a blockchain ecosystem, which translates into more product usage, more transactions, higher total value locked (TVL), and higher revenue. Web3 platforms with the most developers tend to attract the most end users, and vice versa, creating a virtuous cycle.
The Ethereum Foundation realised this early on, regularly awarding millions in grants to teams who could improve the developer experience on the Ethereum blockchain. As soon as Circle launched USDC in 2018, they spent most of their time and resources “building out APIs and developer tools and documentation.”
The number of new developers entering web3 is decreasing. The last bull markets brought a flurry of new developers into the space, but this time around, we are not seeing the same surge. With a limited number of developers, the fight for platforms to gain mind share is fiercer than ever.
DevX is the way to differentiate. We spoke to dozens of developers and experts, and all of them agreed on one thing: DevX in web3 sucks. A poor DevX is leading to reduced adoption and increased churn. Platforms who can win developers will win the market. This article aims to explore some simple principles web3 companies can use to improve their DevX.
What great DevX in Web3 looks like—House of DevX
There are many good frameworks for thinking about DevX. We especially like Swyx’s Radiating Circles framework, and James Parton’s DevRel Framework and Developer Journey.
We take a different approach. Traditionally, web3 companies have focused on hiring in Developer Relations (DevRel), but we argue that their role should be broader. DevX is not just DevRel. We think about DevX from a bird’s eye view and how it should be embedded in an organisation. We call our framework the House of DevX.
A great DevX covers several elements and spans across the organisation:
DevX strategy. A great DevX starts with a clear DevX strategy, which articulates the rationale behind improving DevX and how it drives business outcomes. It should consider the developer journey, use cases, and competitor positioning.
Developer onboarding. This encompasses the educational content and technical documentation which quickly lead the developer to setting up their first application.
Developer tooling. Developers should have multiple options to interface with the underlying product. as well as simulation environments and extensive support tooling.
Developer relations. We include developer content, developer marketing, developer community engagement and developer advocacy in this category.
DevX operating model. The focus on good developer experience should be reflected in team structures, ways of working and business processes. Part of the deployment process of a new feature should be a developer experience checklist, which includes updating documentation and error codes.
Last but not least, DevX needs to receive input from many organisational stakeholders, such as product, engineering, sales, and marketing. In some cases, DevX may even inform these functions. For example, the product team should keep the developer interfaces in mind, the sales team could use developer experience as a selling point, and the engineering team should write their code with the end documentation in mind.
Five ways to improve DevX in web3
Create a North Star Metric for DevX
Just like how your company should have a North Star Metric, DevX itself should have one too. A North Star Metric gives direction, clarity and alignment on what the developer experience team needs to optimise for. It’s also a strong way to communicate the purpose of the developer experience to the rest of the organisation. Some examples of North Star Metrics for developer experience:
Weekly or Monthly Active Developers. You would track this through the use of the API that is provided to developers.
Number of Transactions Through API. This metric is more web3-specific and directly correlated with revenue.
You can then cascade your North Star Metric into smaller metrics which drive accountability at an individual level. For example, if your North Star Metric is Number of Transactions Through API, then the person in charge of writing the documentation for onboarding might contribute to the North Star Metric by optimising the Time to First API Call. The person in charge of managing the developer community might contribute by optimising the Number of Developers Active on Discord. In every case, the developer experience team should be able to articulate the ultimate value to the company. Other metrics which you could track include:
Once the team is aligned on the metrics for DevX, create a live dashboard which shows all of the relevant metrics which anyone in the organisation can access and monitor. Some metrics may require the institution of new processes to collect the data. For example, you may need dedicated team members to measure Time to First API Call by surveying developers. Ideally, market research is done to obtain benchmarks for each metric.
There are plenty of really great articles on how to measure developer experience, including:
Measuring Developer Relations by swyx
How to Measure the Value of Developer Relations by Kim Maida
Focus on the Developer Moments of Truth (DMOT)
“Moments of Truth” in marketing are the touch points when a customer interacts with a brand which can significantly form or change the perception or decision-making regarding that brand. We can similarly apply this framework to the developer experience—we call these moments the Developer Moments of Truth (DMOT). These are the moments which are “make-or-break” for a developer:
Zero moment of truth for DevX. The Zero moment of truth (ZMOT) was first coined by Google in 2011 to describe the research phase before a customer interacts directly with a brand, primarily through digital means like reading reviews or seeking recommendations. Applying this to DevX, the ZMOT is when a developer first hears about your product, often through forums, social media, developer communities, or word-of-mouth. They might research your documentation, GitHub repos, and developer reviews before deciding to try it.
First moment of truth for DevX. This is when the developer first interacts with the product—downloading it, making the first API call or writing the first line of code with your platform. In short, the onboarding of the developer should be as quick as possible. Shorten the cycle time for developer account sign-up to the time to first developer action (e.g. API call). Streamline your API authentication, and make generating API keys and access tokens simple. Invest in a quick start guide to explain the API authentication flow.
Second moment of truth for DevX. This is the moment when the developer deploys their code to either a test environment or production environment. It’s particularly important in web3 because transactions cannot be undone, so it’s important to ensure that everything works smoothly and there are no errors. The journey to this moment of truth should be as smooth as possible. Take the developer all the way through comprehensive sample code and embeddable standard components for their use case. Stripe has over 50 sample integrations which they have built themselves. Thirdweb provides a template and a hosted working example for their embedded wallet product.
Third moment of truth for DevX. This is when developers share their experiences with your tool or platform, whether through blog posts, tutorials, speaking at conferences, or simply recommending it to peers. Positive experiences here can transform developers into advocates, extending your reach and influence within the developer community.
We like to think about the Developer Moments of Truth as a flywheel, as the third DMOT evolves to developer advocacy and reinforces the zero moment of truth for other developers.
Structure documentation around key use cases
Poor documentation can become a barrier to adoption, slow down developer productivity, and increase support costs. Yet most companies put little thought into their documentation's information architecture. Developers can, in one glance, spot poorly thought-out documentation. For example, it’s difficult to search for what they want, the navigation side-bar is just a list of jargon, or the “Quick Start” guide is missing.
One simple way to structure your documentation is centred around use cases. This includes both developer use cases, as well as end-customer use cases. For example, the headings should boil down to the simplest actions where possible, such as “Register users”, “Mint an NFT” or “Withdraw payouts”. Alchemy’s documentation does this well, with detailed tutorials for many use cases imaginable.
Unfortunately, we’ve seen many web3 companies simply list concepts in the order they have built them, rather than being thoughtful about how the developer should build for their end customer.
There’s no need to reinvent the wheel here. Many developers have used Web2 documentation before, such as Stripe’s, so there’s no harm in replicating the structure as much as possible. At the very least, most documentation should include an introduction, a glossary of key terms, a “quick start” guide for the most popular use cases, a go-live checklist, troubleshooting guides, and API & SDK reference documentation.
Over-engineer the unhappy path
In the rush to ship new features and capture market share, many companies have adopted a "feature factory" mindset to ship as many features as possible. This is especially true in the fast-paced hype-driven world of web3. Shiny new features are often built with the “happy path” in mind, where the conditions are perfect, and the developer journey is exactly as we imagine.
However, developers inevitably stray off the happy path. If not enough time is invested in fixing the pain points, developers can get stuck down the “unhappy path” for weeks. Common pain points, or developer exceptions, include unhelpful error messages, unclear expectations (around features, roadmap, and pricing), not meeting commitments and SLAs, and lack of observability.
The simplest mindset is to over-engineer when building the unhappy path. Some practical ways you could be doing this include:
Create user-focused error messages and codes. Error messages should be designed for the developer and structured logically. Immutable offers a comprehensive breakdown of each error scenario, its likely causes, displayed error messages, and recommended actions for developers and end-users. In Web2, Stripe details their error codes and handling documentation in multiple programming languages (e.g. Ruby, Python, PHP, Java, etc). Error messages can even be a way to reinforce your company’s branding—playful and thoughtful messaging that is aligned with a brand’s value.
Over-communicate pricing, downtimes, missing features and roadmap uncertainties. As a web3 company, developers understand that you may not have complete clarity over the product roadmap. But they appreciate honesty and not being misled. For example:
Communicate the missing or incomplete set of features upfront in the documentation.
Provide developers with clarity over the pricing, laying out different scenarios and examples.
Ensure your status page is up-to-date, and proactively send notifications when your product or service is down (through multiple channels, including email and Twitter). You could use tools like Statuspage to communicate uptime..
Recycle developer feedback into error documentation. If a developer is communicating with your team about a particular issue they can’t resolve, chances are another ten other developers had the same issue and gave up. Perhaps you assisted the developer with their error through emails or Discord messages. Take some time to polish it, and publish it on a “Known issues and errors” page, similar to Polygon. If this is done with AI tools, it will only take a few minutes but save hundreds of hours for your developer users.
More reading:
Error Messages by Jon Crabb (mostly relevant to end-users, but still insightful for developer experience)
Leverage the community
Two things that set web3 apart from other industries is 1) the importance of the community and 2) the ability to shift user behaviour with token incentives. The implication of this is clear: web3 companies should be creating a developer community which is motivated to help each other and contribute to DevX. These are the best people to be writing the documentation, fixing bugs and solving developer problems for others.
Dedicated channels for developers. For example, it is standard practice to have a dedicated Discord or Telegram channel just for developers. Developers should have a direct line of communication to the project’s team—this fosters a sense of belonging and contribution to the project's success.
Grants programs can encourage developers to build and contribute developer tooling on the platform. For example, Arbitrum, Filecoin and Aave all offer grants specifically in the category of developer tooling. The developer community will come up with ideas for developer experience that you may not have thought of, or don’t have the capacity to implement. Some successful grants on Arbitrum include Arbitrum Python SDK and educational content for Spanish-speaking developers.
Airdrops, when used strategically, can do more than just generate hype; they can reward community members for DevX contributions. They reward early developers on the platform and distribute governance and decentralise power across the protocol.
Bug bounty programs have a two-fold benefit of engaging developers meaningfully, but also exposing vulnerabilities in a safe way. MakerDAO, Frax Finance and Stargate Finance are among the many web3 companies offering over $10 million in their bug bounty programs.
More reading:
Bootstrapping developer ecosystems for Web3 protocols by Micheal Tiew from Longhash Ventures
Why Your Web3 Project Needs A Bug Bounty Program by Consensys
About the Authors
Alan Nguyen (Twitter, LinkedIn) is a Product Manager at Constantinople, and previously led Airwallex’s (US$5.5b fintech unicorn) Developer Experience team.
Gary Liang (Twitter, LinkedIn) is the Founder, CEO & CTO of Bloom AI, an AI tutor for universities and high schools.
We have a strong interest in all things technology, developer experience and web3. DM us if you want to chat!
 | A guest post by
|