Gall's Law
Learn it → Apply it → Save as Skill
Every complex system that actually works evolved from a simpler system that worked. No one has ever designed a complex working system from scratch on the first try — and Gall's Law says you shouldn't expect to be the first.
Learn it. Apply it. Save as Skill.
The Dr. Wallace’s Favorite Mental Models is designed to turn useful ways of thinking into reusable tools. Each model gives you a fast visual overview, deeper interactive learning, practical application exercises and an AI-ready Markdown skill you can save for future use.
Instead of merely reading about mental models, you can gradually build your own AI skills library: a collection of portable reasoning skills that can help ChatGPT, Claude, Grok and other AI assistants apply the mental models you value.
A complex system that works is always found to have evolved from a simpler one that worked. A complex system designed from scratch, with no working predecessor, essentially never works — and patching it afterward won't save it.
Two paths to a working system
Important: the law describes how working systems actually came to exist, not a guarantee that any simple start will succeed. Plenty of simple systems never evolve into anything bigger — but almost no complex system skipped the simple stage.
Use it when you're about to design something complex from a blank page.
The model is most useful right before a big build decision: a system rewrite, a new platform, a new org structure, or a new AI agent architecture that no one has actually run yet.
Start → Ship → Evolve → Resist the rewrite.
Gall's Law is less a diagnostic tool than a build discipline. It tells you what order to do things in.
Find the smallest version of the system that could plausibly run today, even if it's embarrassingly limited.
Get that simple version into real use so it meets real conditions you could not have predicted on paper.
Add complexity only to solve problems the simple version actually hit, one layer at a time.
Treat any plan to design the next big version entirely from scratch, with nothing running in between, as a warning sign.
Six things worth understanding before you apply it.
Expand each to see the reasoning, the common objection, and where the pattern actually comes from.
The Law
The exact statement
In its original form: "A complex system that works is invariably found to have evolved from a simple system that worked. The original fundamental error is to design a complex system from scratch, since it never works and cannot be made to work. You have to start over, beginning with a working simple system."
Why it holds
Complexity hides failure
A system has far more ways to be broken than to work. A simple system's few failure modes are easy to find and fix. A complex system designed in one shot has failure modes scattered across every interaction between its parts, and no working baseline to compare against when something breaks.
The MVP link
Why "minimum viable" matters
The minimum viable product is a direct, practical application of Gall's Law: it is the deliberate search for the smallest version of a system that can survive contact with real users, so that the next layer of complexity is added in response to real evidence rather than a guess.
The counterexample
"But Apollo was designed top-down"
Large, formally engineered systems like the Apollo program or a commercial jet's flight-control system are often raised as exceptions. They are better understood as having evolved too: from decades of simpler flight, guidance and rocketry systems that already worked, plus extensive subsystem testing before full integration. The apparent exception still rested on a long chain of working predecessors.
The corollary
Complexity creeps back in
A working simple system that evolves well does eventually become complex. Gall's Law does not promise permanent simplicity. It only insists that the complexity arrive gradually, in a system that kept working at every stage, rather than all at once in a system that has never worked at all.
Off the pattern
Where it stops applying cleanly
Some components genuinely must be specified correctly before anything runs: a cryptographic protocol, a load-bearing structural calculation, a safety interlock. These still benefit from simple working sub-components and incremental integration, but the specific part that must be provably correct is less about evolving through trial and error and more about getting the design right before trial is even safe.
A startup team plans an AI agent orchestration platform.
This is an illustrative example designed to teach the method.
A systems-design heuristic, not a law of physics.
Expand for the origin of the model and its real limits.
Where did Gall's Law come from?
Gall's Law comes from John Gall (1925–2014), an American pediatrician who practiced in Ann Arbor, Michigan, and taught clinical pediatrics at the University of Michigan. He self-published his observations about systems, titled Systemantics, around 1975 after the manuscript was turned down by roughly thirty publishers; a commercial edition followed from Quadrangle/The New York Times Book Co. in 1977, with a Pocket Books paperback in 1978. Gall later revised and retitled the book twice, most recently as The Systems Bible: The Beginner's Guide to Systems Large and Small (2002/2003). Gall did not himself label the idea "Gall's Law" in the original text — the name was attached by later readers, especially in software and startup circles.
Is this a strict law or an informal pattern?
It is an informal pattern drawn from Gall's own observation of organizations and technical systems, not a mathematically proven result. Treat it the way you would treat any well-tested design heuristic: a strong prior worth structuring your build order around, not an ironclad guarantee about any single project.
Does it mean you should never plan or design anything upfront?
No. Gall's Law is about sequencing and validation, not about banning upfront thinking. It argues that the complex, fully-specified version of a system should come after a simpler version has run and proven itself, not that planning is worthless. Large engineered systems that look like pure top-down designs, such as spacecraft or aircraft, typically rested on decades of simpler, separately-proven predecessor systems.
The law is easy to misapply in both directions.
Using it to justify never planning
Gall's Law favors a working sequence, not the absence of architecture or judgment. Skipping design thinking entirely tends to produce a simple system that can't evolve cleanly later.
Confusing "simple to start" with "simple forever"
The law describes a starting discipline, not a permanent constraint. A healthy system is expected to grow in complexity as it evolves — that growth is the point, not a failure of the law.
Treating any simple system as a guaranteed seed
Most simple systems never evolve into anything larger. The law only claims that working complex systems have simple roots, not that simple roots reliably produce complex successors.
Over-correcting into endless prototypes
Shipping a trivial version and never adding the complexity users actually need is not an application of the law — it is stalling disguised as discipline.
Ignoring the need for a guiding architecture
Evolution without any sense of direction tends to produce a tangle rather than a system. Gall's Law works best paired with a loose, revisable architectural vision, not none at all.
Using it to excuse permanent technical debt
"It evolved from something simple" describes how the system got built, not an excuse to leave it unrefactored forever once complexity has made the original shortcuts expensive.
Some builds need a different starting discipline.
Use upfront formal design when...
a component must be provably correct before any real-world trial is safe — cryptographic primitives, flight-control logic, structural load calculations.
Use fixed-interface design when...
multiple independent teams or organizations must agree on a stable interface before any of them can build anything at all, such as an open protocol or legal standard.
Use direct evidence when...
a nearly identical system has already been built and evolved successfully elsewhere; you may be able to start from its proven shape rather than from zero.
One model rarely does the whole job.
Build a Gall's Law build-order prompt.
This browser tool structures your thinking. It does not send your information anywhere or perform AI analysis.
Your AI-ready prompt
Turn this mental model into a reusable AI skill.
Save as Skill converts the model into portable Markdown instructions that teach an AI when and how to apply Gall's Law, what questions to ask, what evidence to seek, what mistakes to avoid and how to structure its analysis.
Build your own Mental Models Skills Library
Save the skills you find useful and organize them into your own reusable library. The Markdown is intentionally model-neutral, so it can be used wherever an AI system accepts uploaded files, project knowledge, custom instructions or reusable text context. Platform capabilities differ, so this is a portable skill file rather than a claim of one-click installation.
For readers who want the nuance.
Didn't some huge engineered systems really get designed top-down from scratch?
Even systems that look like pure top-down triumphs, such as a national space program, were built from subsystems — engines, guidance computers, materials — each separately proven in simpler working form before full integration. The appearance of a from-scratch design usually hides a long chain of working predecessors underneath.
How is this different from "move fast and break things"?
Gall's Law is about sequencing complexity after a working baseline, not about tolerating carelessness. The simple starting system still has to actually work; the discipline is in not adding the next layer of complexity until the current layer has proven itself in real conditions.
Is there a size or domain where this stops being useful advice?
Its clearest fit is software, organizational process and product design, where iteration is cheap and feedback is fast. It gets harder to apply literally in domains where a single failed trial is catastrophic or irreversible, which is why safety-critical and formally specified components are treated as a partial exception rather than a counterexample.