Gall's Law Evolutionary Build
Start with a working simple system, then evolve complexity through use.
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 99%
Gall's Law says that reliable complex systems emerge from simpler systems that already work, whereas a complex design created all at once generally fails and cannot simply be patched into health. Ravikant applies the law to NFTs and web3: simple, portable, programmable primitives can be recombined by many participants into systems no centralized designer could specify in advance. The operating method is to identify the smallest useful core, prove it in practice, and expose pieces that can be extended or composed. Complexity is then earned through observed use and successive working versions. The law does not prohibit ambitious outcomes; it changes the route, replacing top-down completion with an evolutionary sequence in which every stage functions.
Origin
Naval Ravikant introduced Gall's Law as a systems-design rule and used it to explain why simple NFT primitives can evolve into complex decentralized systems.
Core principles
- 01A complex system designed from scratch is unlikely to work.
- 02Working complexity evolves from a simpler working system.
- 03Composable primitives let many contributors extend a system.
- 04Top-down completeness blocks learning from real use.
How to run it
- 1
Define the primitive
Reduce the intended system to the smallest component that creates genuine value on its own.
Pro tip Choose a primitive that can participate in more than one future use.
Watch out A miniature version of the entire complex design may still be too complex.
- 2
Prove it works
Run the simple system with real inputs and users until its core behavior is reliable.
Watch out Do not add layers merely to conceal a broken core.
- 3
Enable composition
Make the working component portable, programmable, or otherwise easy to connect with other working components.
Pro tip Prefer clear interfaces and ownership over central permission for every extension.
Watch out A reusable label does not help if integration still depends on hidden control.
- 4
Evolve from demand
Add capabilities as actual users and contributors reveal needs, preserving a working system at each stage.
Pro tip Let independent experiments compete before declaring one canonical expansion.
Watch out Road-map ambition is not evidence that a layer should be built now.
- 5
Retest the whole
After each extension, verify both the new behavior and the original core before proceeding.
Watch out Accumulated local successes do not guarantee the combined system still works.
In the wild
Ravikant describes NFTs as simple, portable, programmable, and composable. People can combine these primitives into games, social contracts, ownership systems, and other complex structures rather than asking one company to design the final system from the top down.
→ Simple working objects become inputs to an open-ended evolutionary system.
Common mistakes
Designing the final system first
The components and interactions have no working lineage, making failures difficult to isolate or repair.
Adding complexity before proof
New layers amplify uncertainty when the simple core has not yet worked in practice.
Is it for you?
Best for
It is best for software, products, communities, and institutions that can grow through tested increments.
Not ideal for
It is not ideal where a minimum safe system is necessarily complex and cannot be fielded incrementally.
From the transcript
“a complex system designed from scratch never works and cannot be patched to make it work”
“a complex system that works is invariably found to evolve from a simple system that worked”
“people are going to recombine and assemble and compose these primitives to create incredibly complex systems”
From the episode
#542: Chris Dixon and Naval Ravikant — The Wonders of Web3, How to Pick the Right Hill to Climb, Finding the Right Amount of Crypto Regulation, Friends with Benefits, and the Untapped Potential of NFTs
Chris Dixon