Painkillers before vitamins with Juri Strumpflohner
Nx's founders spent four days a week doing Angular consulting and only one day a week on the open-source project itself for years — meaning roughly 20% of their time built a tool that now sees 2 million downloads a week. Juri Strumpflohner's read: that 80% spent inside real client codebases was what told them exactly which painkiller to build.
Juri Strumpflohner is director of developer experience at Nrwl, the company behind Nx, an extensible build system designed to scale monorepos from small projects up to large multi-project codebases.
We get into how Nx's founders, both ex-Googlers who worked on Angular, translated Google's internal Bazel-style tooling into something lighter-weight for the rest of the industry, why Nrwl deliberately hires engineers who are already known figures in the community rather than separate DevRel hires, and the very careful, trust-first process behind taking stewardship of the abandoned Lerna project.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What is Nx, and how does it fit into a project's existing build tooling?
Nrwl is the company; Nx is our open-source product. Nx is a smart, extensible build system that sits on top of tools like webpack or esbuild, helping you run tasks efficiently. It's designed to work whether you're starting with a small React app or scaling up to a large, multi-project monorepo, and it supports both an easy, incremental adoption path and a much deeper plugin ecosystem as your needs grow.
Your founders experienced this exact problem themselves at Google. How did that shape Nx?
Our founders, Victor Savkin and Jeff Cross, are both ex-Googlers who worked on the Angular team. Google famously runs one giant monorepo across the whole company, with dedicated internal tooling, called Blaze internally, and Bazel as its open-source counterpart, to make that work. Bazel is genuinely powerful but complex enough that large companies often need a dedicated team just to set it up and maintain it. When Victor and Jeff left Google, they saw the opportunity to bring similar monorepo benefits to companies outside Google, but in a much more lightweight, approachable form that didn't require a dedicated tooling team. A lot of how Nx actually evolved came from dogfooding — talking directly to client companies, seeing their specific pain points, and feeding that straight back into the open-source project.
Nx is completely bootstrapped. What does the business model actually look like?
It started largely as an Angular consulting business, leveraging the founders' existing connections in that community, with the open-source project growing alongside it. As companies wanted to move into the monorepo space, Nx became central to that consulting work — we'd help set it up, evolve it, and improve code quality for clients, initially mostly around Angular and later expanding into React as the front-end landscape shifted. Today, most of the business is still built around consulting — helping companies build and fine-tune Angular and React applications and customize Nx to their specific internal processes, since Nx is inherently very flexible. On top of that, we introduced Nx Cloud, a subscription product offering remote caching and remote task execution, often with on-premise installations for large companies — a second, complementary revenue stream that's worked well.
Nx now sees around 2 million weekly downloads and over 13,000 GitHub stars. How did it actually grow from an open-source side project into something that popular?
It grew organically, and slowly, by necessity — early on, our developers spent roughly four days a week on consulting work and only one day a week actually pushing the open-source project forward, so realistically only about 20% of total time went directly into the product. But that consulting time generated enormously valuable feedback from real enterprise pain points, layered on top of feedback from a strongly engaged open-source community. I like Tony Fadell's line about needing to build the painkiller before the vitamins — that's the philosophy we applied. When teams first adopt a monorepo, it feels great initially, code sharing is fast, but over time builds slow down dramatically, sometimes turning a five-minute CI run into an hour, completely reversing the initial productivity win. We focused heavily on solving exactly that: detecting which specific projects were actually affected by a given change and running only the relevant build and test commands, rather than rebuilding everything.
Beyond running only the affected projects, what else did you build to address that specific pain point?
Layered on top over time: smarter parallelization and task ordering for efficiency, and caching, so a project that hasn't meaningfully changed gets restored instantly from cache instead of rebuilt. Nx Cloud extends that further by distributing the cache — your CI system can build and populate the cache overnight, and when a developer starts work the next morning, their local tests restore instantly from that shared cache rather than rerunning from scratch. That's the painkiller. But Nx also includes what I'd call the vitamins — code generation, a plugin system for scaffolding new projects consistently, and automated migrations for underlying tooling, which is a hugely underestimated need, since upgrading tooling rarely gets dedicated budget on its own, especially over the long, multi-year lifespan of a large company's codebase.
How much did being open source from day one, rather than converting to it later, matter for that growth?
It mattered enormously, and it was a deliberate choice from the start — our founders had already worked on Angular, itself open source from the beginning, and they were committed to that model despite the real financial and sustainability challenges it creates. Five years in, we're still growing quickly — download volume nearly doubled in the last six months alone. A big part of sustaining that is deep community involvement: when you set up an Nx project today, you get out-of-the-box integrations with things like Cypress, Jest, and ESLint, and we maintain close, ongoing relationships, including private Slack channels, with those tool maintainers so we get early visibility into upcoming features and can have Nx integration ready the moment they launch — a genuinely mutual benefit.
You've mentioned hiring people who are already prominent voices in the community rather than treating DevRel as a separate function. Why?
A lot of our engineers, several of them Google Developer Experts, are deeply engaged with the community as a natural extension of their engineering work, speaking at meetups and conferences on their own initiative. From a growth perspective, that's incredibly valuable — these are people with their own existing audiences and relationships, which naturally extends to promoting Nx itself. I genuinely appreciate not needing to personally be on every podcast or at every conference, because these engineers are excited to submit their own conference talk proposals and often come to me having already been accepted somewhere to talk about Nx. I actually started this way myself — as a JavaScript architect focused on consulting and engineering, and only gradually shifted toward more community-facing work, which I think is a genuinely valuable path if you want to grow within a community rather than being hired cold into a pure advocacy role.
You took over stewardship of Lerna, an existing open-source project. What was the actual story there?
Lerna was one of the earliest JavaScript monorepo management tools, but about two years before we got involved, active development had stalled because the entire maintenance burden had fallen onto a single maintainer who understandably burned out — Lerna wasn't a toy project, it had one to two million weekly downloads and real organizations depending on it. Eventually someone opened a PR adding a large notice to the top of the README declaring it unmaintained and effectively deprecated, pointing people toward alternatives like Yarn workspaces, pnpm workspaces, Nx, or newer tools like Turborepo.
How did you actually approach taking it over, given the risk of the community feeling like it was being absorbed or discarded?
We reached out to the original maintainer directly, explained our philosophy around open source, including that we already sponsor a number of the projects we integrate with, and made clear we weren't looking to take it over and quietly let it die or monetize it in a way that would betray the community's trust. They were genuinely happy to hand it over given that context, and we took over stewardship at the end of May, releasing Lerna 5, refreshing the website and docs, and adding an option to run Lerna's existing commands through Nx underneath via a simple flag — meaning people keep the exact same commands and workflow they already know, just running dramatically faster. We were honestly a bit worried about backlash going in, but the feedback has been overwhelmingly positive, with a lot of people upgrading and projects like RedwoodJS integrating with Nx Cloud as a direct result.