Critical path infra for developers with Megan Reynolds from Crane
Gitpod's enterprise customer Factorial has a director of developer experience who loves the product so much his bandmates showed up to his gig holding up Gitpod signs. Megan Reynolds thinks that's not a cute anecdote — it's the actual mechanism by which developer love turns into enterprise sales.
Megan Reynolds is an investor at Crane, a London-based enterprise software seed fund investing across Europe in enterprise infrastructure, with portfolio companies including Gitpod, Encore, and Novu.
We get into why open-source infrastructure tools are proving more resilient in a market downturn than easier-to-cut alternatives, the YC 'hair on fire' framework for validating whether you're solving a real priority problem, and why she thinks a strong open-source community, managed well, is actually the best possible foundation for enterprise sales rather than something in tension with it.
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 Crane actually focus on, and how has the current market turmoil affected the companies you invest in?
We're an enterprise software-focused seed fund based in London, investing across Europe, with a specific focus on enterprise infrastructure — for me personally, mostly open source and developer tooling. We also focus heavily on go-to-market, helping product-led technical founders build that function from seed through Series A. It's been a genuinely chaotic period in public markets, and while private markets are somewhat sheltered, there's a real trickle-down effect when companies can't IPO. But because we invest predominantly in enterprise infrastructure, and that technology tends to become genuinely critical-path within a company's stack, those companies are relatively sheltered — it's very hard to rip out infrastructure that's deeply embedded, especially compared to tools that are easier to cut when budgets tighten. If anything, open-source models are doing even better right now, because they lower the friction for companies to adopt new technology during a downturn.
Is becoming 'critical path' something a company can deliberately engineer, or is it decided at founding?
I think it's deliberate. The companies that do really well deeply understand the specific customer problem they're solving, and make sure the use case they're targeting is genuinely a top priority, not just a nice-to-have, for that user. We call it the 'hair on fire' problem — a YC framing, but a genuinely effective one: is this pain point so urgent that if you handed the customer a literal brick as your product, they'd still use it to put the fire out because they need it that badly? If a company hasn't found and validated that with real customers, they're going to have a hard time.
What do you see founders in developer tools consistently struggling with?
It's closely tied to that — a lot of developer-first founders have a genuine allergy to sales and marketing. I hear it constantly, especially from more technical founders: 'you can't sell to developers, they hate being sold to.' I understand the instinct, nobody likes being sold to, but the actual core of sales is just listening to customers, understanding the value you deliver, and scaling that listening process. There's a real misunderstanding of what sales actually means. On the marketing side, a lot of founders skip developing a genuinely deep understanding of the landscape they sit in — which matters enormously in developer tooling right now, given how crowded and messy it is. If you don't understand where your product sits relative to everyone else, it's very hard to talk about it in a way people instantly grasp — and 'the product is so good it'll sell itself' rarely gets developers to that realization fast enough on its own.
Supabase repositioning from 'real-time Postgres' to 'open source Firebase alternative' seems like exactly that kind of landscape-awareness problem. What made that framing work?
It's catchy — the moment a developer is already weighing whether to use Firebase, and someone tells them there's an open-source Firebase alternative, that message filters through their decision-making almost instantly. It's also a perfect hair-on-fire problem: people were already experiencing real pain with Firebase — it struggles to scale, gets expensive, and locks you in — so the positioning connected directly to an urgent, already-felt problem rather than something abstract.
In a volatile market like this one, what are the strongest developer tool founders doing that others could learn from?
Most of the infrastructure companies we invest in eventually need to transition from a developer-led, often open-source motion into an enterprise sales motion — and timing that transition well is critical. Companies that try to go top-down too early tend to damage both the product and the community. The best companies manage that transition deliberately: build something individual developers and teams genuinely love first, then use everything learned from that community's feedback to inform the move into enterprise, rather than abandoning the community-first approach prematurely.
Can you give a concrete example of a company that's navigated that transition well?
Gitpod, which we invested in a couple of years back, built the best product in the market for cloud developer environments, and spent their first few years almost entirely focused on making the product the best it could be for the specific developers who loved it — when we did diligence, their community told us flatly they'd never go back to anything else. Over the last year, they've started getting real enterprise interest with specific internal use cases, and they've managed to convert that grassroots love into genuine champions inside large organizations. One of their enterprise customers, an HR software company called Factorial, has a director of developer experience who loves Gitpod so much that his bandmates showed up to one of his gigs holding up Gitpod signs. That's not just a cute story — it's a real signal of how effectively they've turned community love into internal enterprise advocacy, rather than alienating that community by moving upmarket too aggressively.
Does that mean a strong developer community is actually an asset for enterprise sales, not something in tension with it?
Enormously so. Being genuinely good at building community makes a company good at enterprise sales too — not in a pushy, product-shoving way, but by creating authentic value for people inside an organization who already believe in what you've built. Those are exactly the kinds of founders and companies we love investing in at Crane — the ones who manage that transition well rather than treating community and enterprise as separate, competing priorities.
What's an example of a recent investment, and what made you back it?
Our latest investment is Novu, an Israeli company building open-source notification infrastructure. The team is exceptional and had built companies before — but what really drew us in was that they'd personally lived through the pain of building notification infrastructure from scratch at every company they'd started, then having to rebuild it again as those companies scaled. It's tedious, largely undifferentiated engineering work that isn't what developers actually want to spend their time on. Their core insight was that nobody should have to build this system repeatedly, so they open-sourced it, and we invested shortly after to help them build the company around it — essentially giving any developer the kind of notification infrastructure a company like Slack or Microsoft has, from day one.
What made Novu's specific angle on notifications different from existing approaches?
The prevailing assumption had been that notifications are fundamentally a product problem — something for product managers to figure out around user engagement. Novu's insight was that it's actually an engineering problem, since engineers are the ones who have to build and maintain the underlying system, and that complexity has only grown with the rise of multi-channel providers like Twilio. When they put out early content framing it that way, the reaction from developers was overwhelming — a lot of engineers immediately recognized themselves as the ones actually responsible for this problem, which validated going open source and building a genuine community around it.
Is that pattern — recognizing an engineering problem previously treated as a product problem — a broader investment thesis for you?
Yes, and I'd genuinely love to see more companies built around it — infrastructure software targeting developers directly, making it easier for them to build applications, especially in categories where the current dominant approach is oriented toward product, sales, or marketing teams instead of the engineers actually doing the work. That's a core thesis for me at Crane, and I'm always happy to talk to founders building in that space.