01 / WHO THEY ARE NOWThe quiet workhorse
It is a Tuesday morning at a company you have heard of. Somewhere on a build farm in Northern Virginia, a CI job that used to take 47 minutes now takes 7. Nobody throws a party. Nobody tweets. An engineer named Priya gets her pull request merged before her coffee goes cold and moves on to the next thing. That coffee, that uneventful merge, that absence of swearing at Jenkins - that is Gradle Technologies' product working exactly as intended.
Gradle Inc. - they prefer Gradle Technologies in formal company - is the San Francisco firm behind two things you have almost certainly used without knowing it. The first is the Gradle Build Tool, an open-source piece of plumbing that gets pulled down more than thirty million times a month and ships, by default, with Android Studio. The second is Develocity, the commercial platform that sits on top and turns a build system into a piece of observable infrastructure.
The company employs around 170 people, mostly remote, scattered across continents the way a well-distributed build cache is scattered across regions. It is profitable enough, well-funded enough, and unfashionable enough that most people in the industry would struggle to name a single executive. Which is, in its own way, the point.
02 / THE PROBLEMWhere the day actually goes
If you survey software engineers about what slows them down, you will get poetry about meetings, manifestos about Slack, and a long, weary section about builds. The build. The thing that has to happen between writing the code and knowing whether the code is wrong. At a small startup it takes ninety seconds. At a large bank it takes ninety minutes. Multiplied across thousands of engineers and tens of thousands of pull requests, that delta is, depending on how you count, somewhere between a luxury sedan and a small acquisition every quarter.
Hans Dockter saw this in 2008, working as a consultant on enterprise Java projects, watching teams negotiate with Ant scripts the way prisoners negotiate with weather. Apache Maven, the consensus alternative, was rigid in the way XML is rigid - which is to say, total. Dockter wanted something that could be configured by people who liked code, not by people resigned to it.
The result, drafted with Adam Murdoch in Melbourne, was Gradle: a build tool whose configuration files were themselves real programs, written in Groovy and later Kotlin. The pitch was simple and almost suspicious. What if your build system was, you know, programmable.
03 / THE BETAn elephant in Melbourne
The early years of Gradle the company - then briefly named Gradleware - were the unglamorous kind: consulting gigs, training days, hand-written documentation, and a steady drip of contributors who kept showing up because the project, against the odds, kept getting faster. Google noticed first. In 2013, Android Studio adopted Gradle as its default build system, which is the kind of integration decision that quietly remakes a market.
True Ventures led a $4.2M seed in 2014. Bain Capital Ventures came in on Series B. In November 2021, Triangle Peak Partners led a $27 million Series C, joined by DCVC, Harmony Partners, StepStone Group and existing investors. Total raised: $53.2M. For a sixteen-year-old company with an open-source distribution engine, it is a remarkably restrained number - and the kind of capital structure that suggests the founders read their own term sheets.
What you can actually do with it
- Build, daily. Define how your code becomes an artifact. Java, Kotlin, Android, Scala, C++, Swift, JavaScript - Gradle does not care.
- Cache aggressively. Skip work that's already been done, locally or across a whole engineering org.
- Distribute tests. Fan out flaky test suites across hundreds of agents and reassemble the result.
- See what happened. Build Scans give you a shareable, deep-linkable report for every build, green or red.
- Stop chasing ghosts. Develocity's failure analytics tell you when a test is flaky vs. genuinely broken - the difference between a Tuesday and a bad Tuesday.
A short history of a long compile
04 / THE PRODUCTBuild system, observed
It helps to understand that "Develocity" is, at its core, a piece of infrastructure that takes the build - that opaque, frustrating thing - and makes it legible. Every run becomes a Build Scan, a shareable URL with a graph of what ran, when, why, and in what order. Caches are shared across a whole organization, so the work one engineer does on a Tuesday is not pointlessly redone by their colleague on a Wednesday. Tests are distributed across a fleet. Failures are clustered and classified. Predictive Test Selection - Gradle's quietly impressive bit of machine learning - runs only the tests likely to be affected by a given change, which is the engineering equivalent of not eating the entire menu to decide what you like.
The Gradle Build Tool itself remains free and open. That is the bargain. The community gets the workhorse. The enterprise gets the dashboard. The company gets a sustainable, sleeve-rolled-up business model that does not depend on dark patterns or weekend launches.
Where the time goes (and where Develocity claws it back)
05 / THE PROOFLogos, downloads, receipts
Develocity's customer roster reads less like a sales deck and more like an engineering recruiting page: Airbnb, ASML, eBay, Fitbit, LinkedIn, Microsoft, Nasdaq, Netflix, Pinterest, Salesforce, Square, Twitter. These are not companies that adopt a build platform on a whim. They adopt it because some staff engineer ran the numbers, made a slide with the words "developer hours" in it, and the CFO eventually stopped arguing.
Then there is the open-source half: thirty million Gradle Build Tool downloads per month, a deep bench of plugins, and the default-build-system-of-Android footnote that means - whether they know it or not - most of the apps on most of the phones in most of the pockets in the world were assembled by a piece of software written, originally, by two people in Berlin and Melbourne who were bored of Ant.
06 / THE MISSIONA category, named
Naming a category is the second-hardest job in enterprise software, after explaining the category to your spouse. Gradle's contribution to the discipline is the phrase "Developer Productivity Engineering," abbreviated DPE, which the company has spent the better part of a decade legitimizing through events (the annual DPE Summit, with keynotes from Google, Meta and DX), training (DPE University), and certifications. None of this is glamorous. All of it works, slowly, the way build tooling itself works.
The implicit pitch is straightforward: software organizations measure shipped features, error rates, and uptime. They do not, consistently, measure developer feedback loops - which is to say, they do not measure the thing most engineers would tell you matters most. DPE is the proposition that you can, and should, and Gradle would like to sell you the dashboard for doing so.
07 / WHY IT MATTERS TOMORROWThe age of large, slow code
Generative AI has, somewhat paradoxically, made Gradle's job more important, not less. When an LLM can produce a thousand lines of plausible code in a minute, the binding constraint on shipping software is no longer typing. It is verifying. Builds, tests, integration, observability - the part where you decide whether to trust the thing you just wrote. The companies that will win the next five years of software are the ones whose feedback loops are measured in seconds rather than coffee breaks. Gradle Technologies has been building toward that future since well before anyone called it that.
Back to Tuesday morning, then. Priya's coffee is still hot. Her PR is merged. Somewhere on a build farm in Northern Virginia, the cache hit ratio just ticked up by half a percent. Nobody throws a party. Nobody tweets. The elephant, quietly, remembers.