Carmack: id's post-Quake mistake was building tech, not a company

What happened

John Carmack posted a rare bit of post-mortem on X this week, looking back at the years immediately after Quake's 1996 release and naming what he thinks broke id Software's trajectory. The thread isn't a confession — Carmack rarely does those — but it is unusually specific about decisions he now regards as mistakes: splitting the engineering team into two parallel product tracks (Quake II and Quake III), licensing the engine to anyone who could pay rather than picking a few strategic partners, and treating id as a research lab that occasionally shipped games rather than a product company that occasionally did research.

The throughline of Carmack's reflection: id had the best technology in the industry for most of a decade, and it didn't matter, because Valve, Epic, and Blizzard were building companies while id was building engines. The post lands at 513 points on Hacker News, which is high for a retrospective tweet with no news peg, and the comment section is the usual mix of ex-id people, ex-Epic people, and engine programmers who have spent twenty years arguing about this exact question.

The specific failures Carmack names are concrete. The Quake II team and the Quake III team were running in parallel on separate codebases, with separate art pipelines and separate design philosophies — one a single-player military shooter, the other a stripped-down multiplayer arena. Carmack now says this halved id's shipping cadence without doubling output, because the two teams were small enough that neither had the bench depth to ship cleanly. Meanwhile, Valve took the GoldSrc fork of the Quake engine, built Half-Life on top of it, and ate id's lunch in the single-player FPS market that id had invented.

Why it matters

The Carmack post is being read on HN as a gaming-industry war story, but it's actually a clean case study in a failure mode that recurs in every technical company: confusing technical leadership with market leadership. id in 1997 had the best renderer, the best networking code, and arguably the best programmer alive. It also had no product strategy, no franchise discipline, and a business model — engine licensing — that subsidized competitors who would then out-ship them.

Compare the trajectories. Valve in 1998 was a startup with no engine of its own. They licensed Quake tech, hired a writing team, built Steam five years later, and are now privately held at a valuation that nobody can pin down because they've never needed outside money. Epic in 1998 was a shareware shop. They built Unreal, then Unreal Tournament, then licensed the engine aggressively but kept the franchise, then pivoted to Fortnite, and now the Unreal Engine is the default 3D pipeline for film, architecture, and automotive. Both companies treated technology as a means. id treated it as the end.

The HN comments include several from people who were inside the studio. The recurring theme is that id's engineering culture was so dominant that design and production were structurally subordinate — design existed to give the engine something to render. This worked when the engine was so far ahead that any game built on it would sell, which was true through Quake. It stopped working the moment Half-Life shipped, because Half-Life proved that a slightly older engine wrapped in a better game beat a better engine wrapped in a worse game. id never fully internalized this, and the Doom 3 / Rage / Doom 2016 arc is the long unwinding of that initial misallocation.

The Broadcom-style insight here is that vertical integration of "we make the thing AND the thing that makes the thing" only pays off if you have the org headcount to do both well. id at its peak had roughly 25 people. Valve had several hundred by the time Half-Life 2 shipped. You cannot simultaneously be the best engine company and the best game company at 25 heads, and Carmack is now saying — twenty-five years later — that the team should have picked one.

What this means for your stack

If you're running a small engineering org, the directly transferable lesson is about team splits. Carmack's specific regret is that the Quake II / Quake III split looked like parallelism and was actually fragmentation. Two teams of 8 don't ship twice as fast as one team of 16; they ship roughly the same amount, with two codebases to maintain, two release cadences to coordinate, and twice the surface area for the bus factor to bite. The heuristic: don't split a team until each half has enough senior engineers to survive losing one of them. Below that bar, you're not parallelizing, you're just halving your effective throughput and doubling your maintenance load.

The second lesson is about platform-vs-product. If you're building infrastructure that other teams (or other companies) consume, you have to make a real choice about whether the platform is the business or a means to the business. AWS made the choice (platform is the business, Amazon retail is a customer like any other). id never made it cleanly — they licensed the engine for revenue but treated it as a side hustle, which meant licensees got worse support than they should have, and the engine evolved to serve id's next game rather than the licensee ecosystem. The pattern repeats today in every startup that ships an open-source core and a SaaS product without deciding which one funds which.

The third lesson is on technical debt as a competitive asset. Carmack's instinct was always to rewrite — Quake, Quake II, and Quake III each had substantially different engines. Valve's instinct was to fork and extend — GoldSrc became Source, Source became Source 2, but the underlying lineage runs unbroken from a 1996 codebase. Forking and extending is uglier, but it accumulates institutional knowledge in the code itself. Rewriting throws that knowledge away every cycle.

Looking ahead

Carmack is currently running Keen Technologies on AGI, which is a domain where the same trap is wide open: every well-funded lab has the best tech for a six-week window, then someone else does. The companies that will still be standing in 2030 are the ones that figure out, before they have to, whether they're a research lab, a product company, or a platform — and structure their headcount, release cadence, and customer relationships accordingly. id's mistake was waiting until 2009 to answer that question. The current generation does not have that much runway.