The Framework Was the Funnel: Why Gatsby Had the Vercel Playbook Backwards

The video “How to burn $30m on a JavaScript framework” surfaced on Lobsters recently and is worth treating as documentation of a repeating failure mode. Meteor raised approximately $31.2m total, with Andreessen Horowitz leading an $11.2m Series A in 2012. Gatsby raised $65m across three rounds, closing a $46m Series B in 2021. Rome Tools raised $4.5m in seed funding. Meteor was acquired by Tiny in 2019. Gatsby was acquired by Netlify in 2023 at a price reportedly below its total capital raised. Rome Tools dissolved in late 2023, with the Biome fork surviving as a community project.

The engineers at these companies built genuinely useful things. The failure is structural: open-source framework adoption generates ecosystem density, community, and developer goodwill, but VC investment requires a path to $300m+ in revenue. Those two things don’t convert into each other easily, and the specific technical decisions these frameworks made reveal exactly where the attempted conversion was supposed to happen.

What the discussion around that video mostly skips, though, is the question of why Vercel pulled off what looks like the same strategy. Next.js now has over 9 million weekly npm downloads. Vercel has raised $313m total, including a $150m Series D in 2021. Both Vercel and Gatsby built a popular JavaScript framework and offered a hosted infrastructure product on top of it. One ended in acquisition below capital raised. The other is the dominant deployment platform for frontend teams. Understanding why requires looking at which direction the arrow pointed between framework and platform.

The Inverted Relationship

Vercel was a hosting platform first. The company launched in 2015 as ZEIT, offering a zero-config deployment product. Next.js launched a year later, in 2016, as a React framework. The framework was built to make the platform more compelling, not the other way around. Edge functions, incremental static regeneration, image optimization, and on-demand ISR were all capabilities designed to work best, often exclusively, within Vercel’s infrastructure. When a developer adopted Next.js, they were being guided toward a Vercel deployment, not because Vercel locked them in technically, but because that’s where the full feature set was available. The framework was a customer acquisition mechanism. Its success and the platform’s success were measured by the same metric.

Gatsby inverted this relationship. Kyle Mathews started Gatsby in 2015 as a React-based static site generator. Gatsby Inc. incorporated in 2018, and Gatsby Cloud launched in 2020, two years after the company and four years after the framework. The commercial product was built to address problems the framework had already created: the mandatory GraphQL data layer normalized every content source into a unified schema at build time, which made complex multi-source sites tractable but made build times scale with content volume in ways that competing approaches did not. Gatsby Cloud’s incremental builds, preview infrastructure, and CMS integrations all existed primarily to solve the performance characteristics that Gatsby’s own architecture produced. The framework was primary; the hosting product was a response to it.

That distinction mattered because it determined the competitive position of the commercial product. Netlify and Vercel had built their platforms to host anything. They had no particular reason to make Gatsby Cloud succeed, and every reason to be a credible alternative. Gatsby’s commercial team was competing against platforms that were structurally indifferent to which framework their customers used. Vercel was competing against platforms that were structurally indifferent to which framework their customers used too, but Vercel had one of those frameworks under direct development, tuning it to generate demand for the platform specifically.

How Meteor Ran the Same Problem Earlier

Meteor’s commercial failure followed a similar logic, with a different technical mechanism. The DDP (Distributed Data Protocol) was Meteor’s real-time data synchronization layer, a websocket-based protocol that made counters update across browser windows without explicit WebSocket code. In 2012, this was genuinely impressive, and the demo converted a lot of developers. The commercial assumption was that DDP’s complexity in production would generate demand for Galaxy, Meteor’s managed hosting product.

The protocol required Meteor on both sides of every connection, which meant there was no incremental adoption path. Introducing Meteor into an existing application meant replacing it with a Meteor application. React arrived in 2013 with an adoption gradient that ran in the opposite direction: a single component in a corner of an existing app, no protocol requirements, no full-commitment migration. As React’s ecosystem accumulated tutorials, Stack Overflow answers, and library integrations, the barrier to adoption dropped continuously. Meteor’s barrier to adoption stayed constant because the architecture required it to.

Galaxy, like Gatsby Cloud, existed to solve complexity that the framework created. Unlike Gatsby Cloud, Gatsby at least had the hosting market grow large enough to acquire the company. Meteor’s Galaxy never found product-market fit against competing managed hosting options, and Tiny acquired the company in 2019 for an undisclosed amount.

Capitalization at the Critical Moment

Timing compounded the structural disadvantage. Gatsby’s $46m Series B closed in 2021. Vercel’s $150m Series D also closed in 2021. Gatsby entered its growth phase with $65m total raised against a competitor that had just added $150m to a position that was already substantially larger. These weren’t parallel races at different scales; by 2021, Next.js had been the dominant React meta-framework for two years.

Ecosystem density compounds in ways that capital cannot directly purchase. Developers choose frameworks and build skills; courses and tutorials accumulate around those choices; recruiters search for those skills; job listings create demand for that knowledge; developers follow the demand. Once Next.js crossed a critical adoption threshold around 2020, the self-reinforcing cycle had already closed. Reversing it required either overwhelming capitalization or a technical differentiation significant enough to shift developer preferences at scale. Gatsby had neither at the moment the divergence locked in.

What the Successful Models Share

The JavaScript frameworks that have sustained themselves fall into patterns that avoid the direct adoption-to-revenue conversion problem entirely.

React and Angular are internal infrastructure at Meta and Google respectively. Neither is expected to generate revenue for its parent company. The investment is justified as engineering infrastructure, recruiting, and ecosystem influence; no investor expects a 10x return on the React team’s salaries because those salaries are overhead for teams that build products that do generate revenue.

Vue.js runs on distributed patronage through OpenCollective and corporate sponsorships. Evan You is compensated, the project is maintained, and there is no expectation of 10x returns because the funding model is grants and donations, not equity investment.

Svelte occupies a middle position: Rich Harris joined Vercel in 2021, aligning Svelte’s development with a company that benefits from Svelte adoption without making the framework itself a revenue line. The framework gets institutional support without VC expectations attached directly to it. This is structurally similar to what Vercel did with Next.js, though with different capitalization requirements because Svelte was already established when the relationship formed.

The common thread is that in each case, the framework’s success is not the thing that must generate the return on capital. For Meta and Google, the return is in the products built with the framework. For Evan You, there is no VC return to generate. For Svelte at Vercel, the return shows up as reduced customer acquisition cost on the hosting platform, not as framework subscription revenue.

Reading the Funding Structure as Signal

The funding structure of a framework is information about its long-term trajectory that most developers don’t explicitly reason about when choosing dependencies. A framework backed by significant VC investment, with a commercial hosting product designed to address complexity the framework creates, is in the pattern the video documents. That’s not a guarantee of failure. Gatsby is still maintained post-acquisition, and Meteor still runs production applications for many teams. It tells you something about the incentive structures in play and the conditions under which the project continues receiving serious investment.

The more durable positions are frameworks where the commercial incentive is aligned with developer adoption rather than framework-specific revenue: internal tooling at a large company, patronage models without 10x expectations, or institutional backing where the framework’s success is measured in platform growth rather than framework sales. The Vercel model technically qualifies, but it required $313m in platform capital to make the closed loop function at scale, and it required being first with that loop in the React ecosystem. The lesson for anyone trying to replicate it is not just to build a platform before a framework; it’s that the loop has a minimum viable capitalization requirement, and getting there second costs substantially more than getting there first.