The Revenue Model That Was Never There: Why VC Money Keeps Failing JavaScript Frameworks

A YouTube talk titled “How to burn $30m on a JavaScript framework” is making rounds on Lobsters, and the framing is more precise than it first sounds. It is not really about mismanagement or bad engineering decisions. The deeper problem is that JavaScript frameworks and venture capital are structurally incompatible, and the developers who keep raising that money are learning it the hard way.

The title treats $30m as a punchline, but the actual mechanism worth understanding is the one that keeps producing the same outcome across different frameworks, different founders, and different funding rounds.

What Venture Capital Actually Needs

Venture capital operates on a specific mathematical assumption: the successful investments in a portfolio need to return ten to a hundred times the invested capital to cover the failures and still generate fund-level returns. A $30m investment, in the typical VC calculus, needs a path to $300m or more in value. That means meaningful, recurring, scalable revenue.

Open-source JavaScript frameworks generate none of that by themselves. They generate adoption. Adoption is not revenue. The distinction sounds obvious when stated plainly, and yet the same mistake keeps getting funded.

Gatsby: The Clearest Case Study

Gatsby is the most documented version of this story. Kyle Mathews built a React-based static site generator that genuinely changed how people thought about the Jamstack. It was fast, it had a rich plugin ecosystem, and for a period around 2018 to 2020, it felt like the obvious choice for content-heavy sites.

In May 2019, Gatsby raised a $15 million Series A led by CRV, with participation from Mango Capital and Trinity Ventures. The pitch was straightforward: Gatsby was one of the fastest-growing open-source projects in the JavaScript ecosystem, and the company would monetize through Gatsby Cloud, a hosted build and preview service.

The problem was structural. Gatsby’s most enthusiastic users were already deploying to Netlify and Vercel, both of which had made their platforms Gatsby-compatible as a deliberate customer acquisition strategy. Gatsby Cloud was competing for hosting revenue against companies whose entire business model was built around hosting Gatsby sites. The framework had created the market, then found itself locked out of it.

By February 2023, Netlify had acquired Gatsby. The acquisition price was not disclosed, which in startup terms usually tells you what you need to know about how it compared to the total capital raised.

Meteor and the Earlier Version of the Same Mistake

Gatsby was not the first to run this play. Meteor raised $11.2 million in a Series A from Andreessen Horowitz in 2012, one of the largest early-stage investments of that era in developer tooling. The Meteor framework was a genuinely innovative full-stack reactive system, and the hype around it was real. Ryan Dahl’s Node.js had just established that JavaScript on the server was credible, and Meteor made building real-time applications feel easy in a way nothing else did.

But React arrived in 2013 and started absorbing all the developer attention. Redux and the Flux pattern addressed state management in a way that fit how developers already thought. The ecosystem reorganized around component trees and the virtual DOM, and Meteor’s integrated full-stack model stopped feeling like an advantage and started feeling like lock-in. Meteor eventually pivoted to Galaxy, a hosting product, and later to enterprise support contracts. The path to venture-scale returns never materialized.

The pattern is identical to Gatsby’s: build something genuinely useful, raise money on the adoption curve, discover that adoption does not convert into the revenue structure VC requires, and sell or pivot.

Rome Tools and the Smaller Version

Rome Tools shows that the same failure mode operates at smaller funding levels too. Sebastian McKenzie, the creator of Babel, raised a $4.5 million seed round to build an all-in-one JavaScript toolchain: linter, formatter, compiler, bundler, and type checker in a single unified tool. The vision was compelling. The JavaScript toolchain in 2021 was a tangle of independently maintained projects with incompatible assumptions, and a unified approach made real sense.

In late 2023, Rome Tools the company dissolved. The Biome fork emerged almost immediately from the community, picking up the codebase and continuing development as a volunteer-maintained project. The engineering work survives; the company did not. $4.5m is a smaller number than $30m, but the mechanics were the same.

The Frameworks That Did Not Need This Model

It is worth spending time on the frameworks that succeeded and how their economics actually worked, because the contrast is instructive.

React was built at Facebook for Facebook. The engineering investment was justified entirely by internal product needs, and open-sourcing it was a strategic choice to reduce the cost of hiring and to benefit from external contributions. Facebook never needed React to generate external revenue because React was never a product for Facebook, it was infrastructure. The same logic applies to Angular at Google.

Vue.js took a different path. Evan You built it independently and has sustained it primarily through GitHub Sponsors and the Open Collective, supplemented by corporate sponsorships from companies that use Vue in production. The funding model matches the value delivery: people and companies who benefit from Vue pay to support its continued development. There is no VC expectation of 10x returns, which means there is no pressure to invent a monetization scheme that does not fit the product.

Vercel represents the only model that has worked at VC scale, and it does so by not really being a framework company. Vercel is a cloud platform company that funds Next.js development because Next.js is a customer acquisition funnel. The framework makes the platform more attractive; the platform generates the revenue. The distinction matters because Vercel’s investors are not betting on Next.js generating direct revenue. They are betting on the platform business that Next.js supports.

What This Says About the JavaScript Ecosystem

The JavaScript ecosystem produces frameworks at a rate that seems absurd from the outside but makes sense if you understand what drives it. Building a framework is tractable. Building a business on top of a framework is not. The former requires deep technical skill and creative thinking about abstractions; the latter requires a revenue model that is genuinely hard to construct in open-source software.

The stories that keep getting funded share a common pitch structure: large adoption numbers, a plan to capture value through a hosted service or enterprise tier, and the implicit assumption that the relationship between developer adoption and business revenue is more direct than it turns out to be.

Developer tools are hard to monetize because developers are extremely price-sensitive on tools they use privately and often operate within procurement processes that are slow, political, and biased toward existing vendor relationships. The people making the technical choice to use a framework are often not the people with budget authority, and even when they are, the instinct is to treat open-source tools as free rather than as subscriptions.

The $30m framework problem is not really a JavaScript problem or a framework problem. It is a pattern that emerges whenever VC money meets a category where the value created and the value captured are structurally decoupled. JavaScript frameworks just happen to be a particularly clear instance of that pattern, because the adoption curves are steep and visible and the revenue never quite follows.

The talk title treats it as a cautionary tale about execution. The more durable lesson is about the category itself.