10000th PR on Harness Developer Hub

Ten thousand pull requests. 

That number isn’t just a metric - it represents ten thousand moments of improvement, feedback, collaboration and evolution on the Harness Developer Hub (HDH), the central documentation site for everything Harness.

In the world of software delivery, we talk a lot about velocity, developer experience, and continuous improvement. None of that happens in a vacuum, and one of the most powerful ways to drive value quickly is through accessible, high-quality, up-to-date documentation. That’s why we built HDH—and now, with 10,000+ contributions completed, it’s time to reflect on what we've built, what we've learned, and where we’re going.

Why This Milestone Matters

This blog is a celebration of our 10,000th pull request on HDH — but it’s also a story. Before the launch of the Harness Developer Hub (HDH), we relied on a centralized documentation model built on HelpDocs. While it served as a single source of truth, the experience was inherently limited. The real challenge wasn’t just about maintaining docs - it was about how fragmented the broader learning journey had become.

Technical information lived across multiple systems - blogs, support articles, engineering wikis, internal runbooks - and users were often left chaining things together. Even internally, context was scattered. The result was a disjointed experience that didn’t reflect the velocity or openness of our product.

Journey to 10,000

We launched HDH to rethink this from the ground up. Not just as a new site, but as a product in itself with a few clear goals:

• Bring all learning resources under one umbrella: Documentation, guides, examples, FAQs - all in one place, with a consistent structure and search experience.
  
  
• Design for decentralization: Rather than routing all changes through a central docs team, we enabled product teams, field engineers, and community members to contribute directly, just like they would to an open-source project.
  
  
• Docs-as-code model: Every doc lives in version control. Every update happens through a pull request. This gives us visibility, reviewability, and traceability just like product code.
  
  
• Support our open-source mantra: We believe in transparency, and that includes our documentation. Anyone can see how things work, suggest improvements, or fork content to build on top of it.

HDH was never meant to be just a better doc site. It’s a core part of our product experience, one that’s versioned, validated, and evolved like any other part of the codebase. 

We treated documentation as part of the product surface area - and gave it the same tooling, care, and velocity as the features it supports.

Lessons Learned

Start with the Developer, Always

One of the most important decisions we made early on was to write for developers and not just about our product, but through the lens of how it’s actually used. We prioritized real-world examples, step-by-step guides, and configuration-driven walkthroughs over theoretical traditional technical documentation. This developer-first approach built trust. It gave users confidence that what they saw in the docs would work in their environments—and if not, they could suggest improvements directly.

Documentation is the Product

One of the most impactful choices we made was to treat documentation like we treat software. By putting everything in Git—version-controlled, peer-reviewed, and managed through pull requests we unlocked the ability to move fast without compromising on quality.

This shift meant that:

• Engineers and PMs could contribute directly, using the same workflows they already knew.
• Reviews became more collaborative, with real-time feedback across teams.
• Documentation would no longer be an afterthought but an integral part of every release.

This wasn’t just a tooling change - it was a mindset shift. We stopped thinking of docs as static artifacts and started treating them as part of the product.

Building HDH with Our Own Platform

We didn’t just use Harness to write about features - we used it to power the entire Harness Developer Hub. Our CI pipelines automatically lint and validate content. GitOps triggers handle seamless deploys every time a PR is merged. Every improvement to the docs goes through the same automation & review flow we recommend to our customers.

This approach gave us two key benefits:

• We validated our own product in a real-world, production use case.
• We created a constant feedback loop between our DevRel team (Team that manages docs in Harness) and our product and engineering teams.

The result? HDH became more than a site for documentation. It became a working demonstration of how to ship quickly and confidently using Harness.

Community Impact

Accelerating Onboarding and Adoption

We’ve seen firsthand how strong documentation shortens time-to-value. Whether it’s a new engineer deploying a pipeline for the first time, or a customer exploring a new module, HDH today helps users move from exploration to execution quickly and confidently.

One standout example is the growth of Harness University, our structured learning and certification platform, which also lives on HDH. Earlier this year, we celebrated our 3,000th certification issued — a major milestone that reflects how far we’ve come in building an ecosystem of Harness-certified experts. The same foundation that powers our documentation - clarity, version control, and community feedback - also supports our learning experiences.

Contributions That Made the Biggest Difference

Some of the most impactful contributions didn’t come in the form of large rewrites - they were the quick fixes:

• A clarification to a flag name that saved hours of trial and error.
• An Interactive Guide that helped a beginner grasp a complex deployment strategy.
• A new example added from a real-world use case that turned a generic doc into something immediately usable.
  
  

These seemingly small changes compound over time. And thanks to our Git-based workflow, these contributions often come from across the organization - devrel engineers, customer success engineers, support, field teams, and even customers themselves.

What started as a company-owned doc site has evolved into a community-owned platform, and that’s what we’re most proud of.

Looking Forward

The next 10,000 PRs will be guided by the same philosophy that got us here:

Documentation is not an afterthought—it’s a product.

And we’ll keep building it like one.

Whether you’re a first-time reader, a contributor, or someone who’s submitted one of those 10,000 PRs — thank you. You’ve helped make HDH what it is today: a living, breathing product that evolves with every commit.

‍