Midnight DevRel quadrupled commits by treating docs as a product

The developer relations team at Midnight didn't just update their documentation. They took ownership, cut nearly as many lines as they added, and tripled their contributor base in six months.

In the six months after taking ownership of documentation, the developer relations team at Midnight reports it increased repository commits from 476 to over 1,900. The change came from a strategic decision: treat documentation not as an afterthought, but as a core product with clear ownership, standards, and dedicated maintenance.

This is a playbook for turning a documentation site from a liability into a developer acquisition asset. The work, according to a post from the team, involved a near-total rewrite, a focus on strategic deletion, and building systems to keep the content current.

Ownership drove a 4x increase in activity

The first step was assigning direct accountability to the Developer Relations team. The results of this ownership were measured in the codebase's git history. Comparing the six months before the handoff to the six months after, the team claims a significant increase in activity.

Commits rose from 476 to over 1,900, a fourfold increase. Merged pull requests grew from 145 to 447. The number of unique contributors tripled, from 21 to 64. The team attributes this growth to treating the documentation as a community project rather than a walled garden.

The most important metric was deletion

Neglected documentation tends to accumulate cruft. The Midnight team reports adding roughly 339,000 lines of code and documentation over six months, but they also removed approximately 281,000 lines. This near-1:1 ratio of addition to deletion was intentional.

The team focused on cutting dead pages, stale tutorials, and redundant explanations. One key example cited is the "Hello World" walkthrough, which they rebuilt from 1,300 lines down to about 300 without losing instructional value. A docs site is judged by what a developer can find and trust, not by how much sits on the shelf.

A curated library of examples

To make the documentation more practical, the team built out a new, progressive examples library. At the start of the year, the library reportedly had only one usable entry. The new library includes a series of tutorials designed to teach specific concepts, from a basic "Bulletin Board" contract to a full-stack "Leaderboard" application.

They also created a new set of example contracts for common use cases like private auctions and token transfers. Critically, the team retired generic examples that could apply to any platform. The goal was to create resources that taught developers something specific about building on Midnight's network.

Automation to prevent documentation drift

Keeping documentation accurate is a persistent challenge, especially when the underlying product changes frequently. To solve this, the team built an automated review pipeline. This system checks every documentation change for quality and accuracy before it reaches a human reviewer.

This process is designed to catch breaking changes systematically. When a recent release altered import patterns across the codebase, the system flagged the outdated documentation, ensuring it could be fixed before developers encountered the errors.

What We'd Change

The Midnight team's playbook is a strong tactical guide for overhauling developer documentation. However, the provided metrics focus entirely on repository activity. Commits, pull requests, and contributor counts are valuable indicators of a healthy open-source project, but they are not business outcomes.

A more complete playbook would connect this work to user-level metrics. Did the new documentation reduce the median time for a new developer to complete their first project? Did it lead to a measurable decrease in related support tickets? Without this data, the return on investment is unclear.

The post also omits the cost of this initiative. The 4x increase in commits and the massive line-count churn represent a substantial investment of developer hours. For a resource-constrained startup, understanding the team size and time commitment required to execute this strategy is critical. The playbook is effective, but its resource intensity may not be suitable for every organization.

Landing

For developer-first companies, documentation is a critical component of the go-to-market strategy. It functions as top-of-funnel marketing, product onboarding, and long-term user support. The Midnight team's account demonstrates how treating docs as a product can revitalize a developer community and create a more useful resource. The next step is to connect repository metrics to the commercial goals of the business, proving that a better developer experience leads directly to user activation and retention.

The investor read

This playbook signals a mature developer-first GTM strategy. Investors in developer tools or infrastructure view investment in the developer experience (DX) as a leading indicator of product-led growth. The metrics cited (commits, contributors) are proxies for community health and ecosystem momentum. While these are not direct revenue figures, a thriving open-source community can be a powerful moat. An investable company executing this playbook would connect these DevRel activities to commercial outcomes: faster developer onboarding, higher activation rates, and lower support costs. This is not a cost center; it is a deliberate, capital-intensive investment in a top-of-funnel asset designed to win a technical audience.

Pull quote: “A docs site is judged by what a developer can find and trust, not by how much sits on the shelf.”