Growing with open source projects - Josh Thurman from Uffizzi
Josh Thurman's first startup tried to out-build Heroku and lost to economies of scale it never had a chance against. His second, Uffizzi, found its market by deliberately going to Spotify's Backstage and other open-source projects first — solving three go-to-market problems, beta credibility, and visibility, at once.
Josh Thurman, a former Navy SEAL, is the founder of Uffizzi, which provides ephemeral preview environments — short-lived, full-stack test environments spun up automatically for every pull request.
We get into the specific dysfunctions of shared dev environments he kept hearing about, why Spotify's Backstage team spinning up 400 ephemeral environments a month became a flagship customer, the deliberate strategy of going straight to open-source maintainers for early credibility, and the failed Heroku-competitor startup that came before Uffizzi.
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 does Uffizzi actually do?
We're broadly in the environments-as-a-service category — preview environments, or ephemeral environments, the terms are used interchangeably. The idea is rapidly creating a full-stack test environment in response to a pull request, iterating there, then completely tearing it down once you're done, hence 'ephemeral.' The underlying problem is that most of the software industry still relies on shared environments, which creates a whole host of problems. Short-lived, per-PR environments let developers, QA, and even product people test and iterate quickly without the ongoing management headaches shared environments accumulate over time.
What are some of the worst shared-environment dysfunctions you've actually seen?
One team had a literal online sign-up sheet for who got to use 'the' dev environment at what time — genuinely contested, physically coordinated access. I've seen developers afraid to merge because they might break the shared environment, so they'd get on a Zoom call to pair-review with someone first just to be safe — pair programming is great, but that's not really what it's being used to solve here. I've also seen people VPN into someone else's machine just to check something. At larger organizations you get capacity-planning problems too — mushroom farms of environments spun up once, used briefly, and left running indefinitely because nobody told DevOps to tear them down.
Why does this problem matter more right now, in this specific economic moment?
Everyone's trying to do more with less — inflation's been high, interest rates are up, there have been real layoffs, and enterprises are trying to get leaner and more agile. Being able to spin up exactly as many environments as you need, exactly when you need them, and only for as long as you need them, reduces reliance on DevOps teams who have higher-priority problems to solve, and empowers developers directly instead of making them wait through artificial code freezes or fear around breaking a shared QA environment. At enterprise scale, a delayed release can cost millions in missed revenue. On the startup side, the pressure is different but just as real — you're racing toward your next round, and any tool that gives you a real, measurable edge in release frequency or development velocity is worth trying, the same instinct I have as a triathlete chasing any 1-3% improvement.
How did Spotify's Backstage team end up becoming one of your flagship customers?
We're spinning up around 400 ephemeral environments a month for them, with roughly 200 engineers using the service. Backstage has 20,000 GitHub stars but around a million end users and 500 enterprises using it, so the maintainers are under real pressure to pack more into every release — they ship a weekly beta and an official monthly release. They're processing hundreds of contributions a month, filtering through around 400 pull requests, from roughly 150-200 active contributors in any given month out of about a thousand all-time contributors. Any time saved on faster PR review compounds enormously at that volume — instead of merging to a shared environment or pulling code locally to test, a reviewer and contributor can look at the exact same live environment tied to that specific pull request, push a fix, and confirm it's good to merge immediately.
You've deliberately targeted open-source projects like Backstage as a go-to-market strategy. Why?
Any startup needs a beta community, which is genuinely hard to build because your product isn't quite there yet and engineers are naturally skeptical of anything unproven. You also need credibility — nobody's using it yet — and visibility — nobody knows you exist. We were at KubeCon in Valencia talking to the Backstage team and realized we could help them directly, and that this same approach could work across tons of open-source projects, solving three problems — beta feedback, credibility, and visibility — at once. It wasn't smooth initially: our first handful of open-source integration attempts genuinely couldn't meet the project's technical needs because of how much variability there is in how people define their app in Docker Compose. That was frustrating, but it forced us to make the product more broadly useful, and once we did, we picked up more open-source projects.
Why does open-source credibility specifically matter so much for a dev tool?
Open-source maintainers tend to be industry leaders working transparently, using the most advanced methods and best practices that the rest of the developer community eventually follows. Having that level of validation — smart, technically rigorous people finding real value in the product — is one of the best signals a founder can get. And because it's all in the open, skeptical engineers can go look directly at the actual implementation in these repos: exactly how it's set up, how it integrates with GitHub Actions, what file defines each ephemeral environment. We support projects like Meilisearch, a fast Rust-based search tool taking share from Elasticsearch, and NocoDB, an open-source Airtable alternative — supporting this new generation of builders taking on established markets has been genuinely exciting, and once teams have ephemeral environments, they consistently don't want to go back to working without them.
How did you actually land on this problem space, given Uffizzi wasn't your first company?
Largely through failure. I spent most of my adult life as a Navy SEAL before exiting the military in late 2018, wanting to get into tech entrepreneurship. My co-founder and I started by trying to build a Heroku competitor, reasoning that Heroku hadn't meaningfully improved in years and was expensive with a mediocre user experience. As first-time founders, we didn't appreciate how saturated and scale-driven that market already was — Digital Ocean launched their own App Platform around the same time, and we simply couldn't compete with the economies of scale Heroku and others already had, even though people genuinely liked our product.
How did you pivot from that failed Heroku competitor into Uffizzi?
By mid-2021 we had some capital, a capable team, and working software, so we used our network to ask if there was a more useful way to repackage what we'd built. People kept telling us the same thing: their developers needed to spin up environments constantly, but they didn't want to host their whole platform with us — they just wanted a temporary testing environment. That became the nucleus of the idea, though it still took real product work to fully transition. We also got a lot of feedback that people wanted tight GitHub Actions integration, so we published a reusable workflow — a lot of teams have heavily customized builds that a generic build solution doesn't fit, which was exactly Spotify's experience with a previous third-party tool whose build process wasn't accessible or under their control. We plug directly into GitHub Actions instead, so teams keep full visibility and control, and we're just one step in a process they've already built themselves.
What did you personally learn from having to abandon that first idea?
It's easy to get emotionally attached to your own idea and reject feedback you don't want to hear. In special operations, we had a phrase for this: don't be a slave to your emotions. You might spend a full day perfecting a plan, and someone with a different, less invested perspective walks up with an objectively better idea — the right response is to recognize you're wrong and adjust immediately, not defend the plan because you're personally attached to it. Running a genuinely high-performing team means being able to take that kind of feedback without getting your feelings hurt over a better way of doing something.
Do most teams already recognize the value of ephemeral environments, or is there real resistance?
We ran a state-of-preview-environments survey at the end of last year with help from the Open Source Initiative to reach a good audience, and 80% of respondents said they think preview or ephemeral environments are valuable. The hard part isn't convincing people of the value — it's the friction of actually adopting the pattern: every new environment means new networking, a new URL, questions about data and how to log in. Those are genuinely hard problems that have kept a lot of teams from making the switch, even when they already agree it would help. That's specifically the friction we're trying to lower enough that onboarding isn't a heavy lift.
If a team already has something that technically works, how do they actually get to the point of prioritizing this?
It tends to come down to the teams under the most real pressure — often open-source projects trying to take share from an already-established incumbent, where any competitive edge is worth grabbing. Backstage is a good example: with companies like Netflix, American Airlines, and Siemens depending on it, there's enormous pressure on that team specifically to keep improving it, especially after layoffs have left engineering leaders expected to keep producing with fewer resources. Those existential pressures, combined with daily friction — engineers literally sitting idle because no environment is available to test in, in 2023 — are what actually force the change.
What's the biggest takeaway you'd want another dev tool founder to walk away with?
Don't be afraid to approach the open-source community directly if you have a tool that can genuinely help them — maintainers are approachable and work in the open on GitHub, so you can reach them there. Just don't do it as a spammy pitch; do it by actually providing value and doing the implementation work for them, not just handing over something and hoping they'll consider it. I'm a strong believer that you have to provide real value before you can extract any — don't be afraid to do things that don't scale early on, specifically to earn the things that eventually let you scale.