DevRel in web3: Building systems that scale while the ecosystem is still taking shape

“Don’t optimize for today. Build the scaffolding for scale.” Intro The pace of web3 is dizzying. Protocols evolve weekly. Docs lag behind releases. Tooling is in flux. Community sentiment shifts with the market. For Developer Relations teams, that means operating in a state of constant motion and navigating uncertainty while trying to create structure and momentum. On our DevRel team at Midnight, we’re not just reacting, we're designing systems that can outlast us. This blog post is a look inside how we're thinking about DevRel in an emerging ecosystem, and what it takes to build not just community, but infrastructure for community. From tasks to systems: The DevRel Flywheel The traditional DevRel playbook doesn’t hold up when the ground keeps shifting. That’s why I’ve shifted from thinking in terms of tasks, such as “write this guide” and “host that hackathon,” to thinking in terms of systems. Enter the DevRel Flywheel. A concept originated by Matthew Revell that we’ve adapted for web3. Here’s how it works at Midnight: Developer activity sparks early traction and interest Community engagement amplifies that momentum Trust and support build confidence and Ecosystem visibility brings new builders and use cases New projects fuel more developer activity The more we feed the flywheel with education, support, and visibility, the less we need to push manually. Our role becomes about momentum maintenance, not manual motion. Mapping the developer journey at Midnight To make the flywheel spin faster, we have mapped the journey a developer typically takes within our ecosystem. This helps us design the right interventions at each stage, and it aligns with Phil Leggetter's AAARRRP framework (Awareness, Acquisition, Activation, Retention, Referral, Revenue, Product) used across DevRel and growth teams. Stage Midnight Journey AAARRRP Phase First Touch Social, talks, blogs, conferences Awareness + Acquisition Education Tutorials, Discord livestreams, ZK workshops Activation Documentation Quickstarts, use-case driven docs, APIs + SDKs Retention Hackathon Build events, project feedback, prizes Retention + Referral Ecosystem Contributor PRs, mentoring, writing, core feedback Referral + Product Growth This journey acts as both a map and a compass. It gives us clarity on: Where we’re losing developers Where we can accelerate outcomes How to tailor support, education, and incentives at each stage We don’t just hope developers stick around. We design the journey so they thrive at every stage. What we’re learning (and unlearning) We’re early in this journey, and we’re experimenting constantly. Here are a few unexpected lessons from our DevRel systems design so far: Education should drive contribution, not just consumption Docs should meet developers by intent, not by section Example apps should collect feedback, not just showcase use Support should default to public and persistent, not private DMs Incentives should build reputation, not just distribute prizes Not everything from web2 works in web3. And sometimes, what didn’t work there is what works here. Rethinking hackathons in web3 I used to be skeptical of hackathons. I worried they were just prize-driven traffic spikes with no long-tail return. But at Midnight? They’re proving to be launchpads. We’re seeing multiple hackathon teams/projects go on to receive grants, and we’re now actively investing in the winners' journeys. This doesn’t mean we won’t keep evolving the format (we will), but it’s changed how I think about incentives, retention, and early-stage builder support across the board. A system that feeds itself What we’re building now will shape the culture and sustainability of our developer community for years to come. If we only optimize for today (fix this doc, answer that question), we’ll burn out before we ever get to scale. So instead, we’re asking: How can we structure support so that our community helps itself? How can we collect feedback so that every new tutorial gets smarter? How can we build with devs, not just for them? An invitation to fellow web3 DevRel builders If you’re doing DevRel in a web3 ecosystem, especially an early one, I’d love to connect. What’s working for you? What isn’t? What does your flywheel look like? Let’s swap notes. Let’s compare scars. Let’s collaboratively build systems that make it easier for the next wave of builders to build what matters! -- ✨

Apr 23, 2025 - 10:37

DevRel in web3: Building systems that scale while the ecosystem is still taking shape

“Don’t optimize for today. Build the scaffolding for scale.”

Intro

The pace of web3 is dizzying. Protocols evolve weekly. Docs lag behind releases. Tooling is in flux. Community sentiment shifts with the market. For Developer Relations teams, that means operating in a state of constant motion and navigating uncertainty while trying to create structure and momentum.

On our DevRel team at Midnight, we’re not just reacting, we're designing systems that can outlast us. This blog post is a look inside how we're thinking about DevRel in an emerging ecosystem, and what it takes to build not just community, but infrastructure for community.

From tasks to systems: The DevRel Flywheel

The traditional DevRel playbook doesn’t hold up when the ground keeps shifting. That’s why I’ve shifted from thinking in terms of tasks, such as “write this guide” and “host that hackathon,” to thinking in terms of systems.

Enter the DevRel Flywheel. A concept originated by Matthew Revell that we’ve adapted for web3. Here’s how it works at Midnight:

Developer activity sparks early traction and interest
Community engagement amplifies that momentum
Trust and support build confidence and
Ecosystem visibility brings new builders and use cases
New projects fuel more developer activity

The more we feed the flywheel with education, support, and visibility, the less we need to push manually. Our role becomes about momentum maintenance, not manual motion.

Mapping the developer journey at Midnight

To make the flywheel spin faster, we have mapped the journey a developer typically takes within our ecosystem. This helps us design the right interventions at each stage, and it aligns with Phil Leggetter's AAARRRP framework (Awareness, Acquisition, Activation, Retention, Referral, Revenue, Product) used across DevRel and growth teams.

Stage	Midnight Journey	AAARRRP Phase
First Touch	Social, talks, blogs, conferences	Awareness + Acquisition
Education	Tutorials, Discord livestreams, ZK workshops	Activation
Documentation	Quickstarts, use-case driven docs, APIs + SDKs	Retention
Hackathon	Build events, project feedback, prizes	Retention + Referral
Ecosystem Contributor	PRs, mentoring, writing, core feedback	Referral + Product Growth

This journey acts as both a map and a compass. It gives us clarity on:

Where we’re losing developers
Where we can accelerate outcomes
How to tailor support, education, and incentives at each stage

We don’t just hope developers stick around. We design the journey so they thrive at every stage.

What we’re learning (and unlearning)

We’re early in this journey, and we’re experimenting constantly. Here are a few unexpected lessons from our DevRel systems design so far:

Education should drive contribution, not just consumption
Docs should meet developers by intent, not by section
Example apps should collect feedback, not just showcase use
Support should default to public and persistent, not private DMs
Incentives should build reputation, not just distribute prizes

Not everything from web2 works in web3. And sometimes, what didn’t work there is what works here.

Rethinking hackathons in web3

I used to be skeptical of hackathons. I worried they were just prize-driven traffic spikes with no long-tail return. But at Midnight? They’re proving to be launchpads.

We’re seeing multiple hackathon teams/projects go on to receive grants, and we’re now actively investing in the winners' journeys. This doesn’t mean we won’t keep evolving the format (we will), but it’s changed how I think about incentives, retention, and early-stage builder support across the board.

A system that feeds itself

What we’re building now will shape the culture and sustainability of our developer community for years to come. If we only optimize for today (fix this doc, answer that question), we’ll burn out before we ever get to scale.

So instead, we’re asking: