Primitives & Compounding Iteration Model
Build reusable technical primitives instead of starting from scratch on every project so each iteration compounds into the next.
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 6
- Confidence
- 80%
This mental model, drawn from Epic's approach to building the Unreal Engine, argues that the fastest way to create durable, compounding value is to invest in small, modular, reusable building blocks ('primitives') rather than rebuilding core capability for every new product. Each iteration on the primitive doesn't just improve one output — it upgrades every future project built on top of it, similar to how invested capital compounds in investing. Acquired frames this as the practical, day-to-day implementation of 'compounding': resource allocation decisions today become the building blocks that make tomorrow's output cheaper, faster, and better, rather than restarting effort from zero each cycle.
Origin
Inspired by Tim Sweeney's decision to build an extensible engine rather than a one-off game after seeing how much proprietary rework John Carmack had to redo for each id Software title.
Core principles
- 01Invest upfront in generalizable, extensible building blocks rather than one-off solutions
- 02Each iteration on a primitive compounds value for every future project built on top of it
- 03Treat resource/engineering allocation like capital allocation, optimizing for compounding rate
- 04Being the first and best customer of your own primitive validates and improves it
How to run it
- 1
Identify a repeatedly rebuilt capability
Find a capability your team rebuilds from scratch across projects, such as rendering or physics code.
- 2
Extract it into a reusable module
Pull that capability out into an extensible, reusable primitive rather than leaving it embedded in a single project.
- 3
Invest upfront engineering time to generalize it
Accept slower short-term output in exchange for building something reusable and extensible.
- 4
Ship the primitive to yourself first
Use the primitive internally as the first customer to stress-test it before or alongside external release.
- 5
License or release it externally
Make the primitive available to third parties to widen its use, refine it further, and build market demand.
- 6
Layer new capability on top rather than rewriting
For future projects, build on top of the existing primitive instead of starting again from zero.
Pro tip Treat each iteration like a capital allocation decision — invest where it compounds fastest.
Watch out It can take years of sustained investment before the compounding payoff becomes visible.
In the wild
Instead of rewriting rendering and physics code from scratch for each game the way id Software did between Doom and Quake, Tim Sweeney built an extensible engine that other studios licensed before Unreal itself had even shipped.
→ Unreal became the reusable base layer for countless AAA games and, decades later, non-gaming productions like The Mandalorian.
Common mistakes
Rebuilding core capability from zero each project
This was id Software's pattern with Doom and Quake — huge feats of engineering that had to be substantially recreated for each new title, sacrificing compounding value across releases.
Underinvesting in generalization to save short-term time
Building a one-off tool instead of an extensible module forfeits the future compounding benefit, even if it ships faster in the moment.
Is it for you?
Not ideal for
Teams shipping one-off products with no intent to build a reusable platform.
From the transcript
“Tim is working on a system that uses primitives, building blocks, rather than sort of starting from zero each time.”
“the sort of methodical small iterations that Epic is able to do uh all of these years on, say on Real Engine compounds on each…”
“iteration is almost like the implementation of the abstract concept of compounding and investing”
From the episode
Epic Games