Laughably Small MVP Under High Stakes
Ship the smallest possible thing even for high-stakes problems — it delivers impact and reveals what to actually build.
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 3
- Confidence
- 88%
The willingness to launch a laughably small MVP is a well-worn trope, but it holds even under extreme stakes. Starting with the minimal version delivers real impact immediately and, crucially, invalidates your assumptions about what you actually need to build — usually revealing you can do something far lighter-weight than planned.
Origin
Zoelle Egner's experience co-running Vaccinate CA, founded from a Patrick McKenzie (patio11) tweet.
Core principles
- 01Even high-stakes problems can start with the smallest possible thing
- 02The tiny version gives disproportionate information about what to build next
- 03Your pre-launch assumptions about required tooling and oversight are usually wrong
- 04A fast-changing environment is a useful forcing function to build small
How to run it
- 1
Strip the idea to its simplest premise
Reduce the concept to a single concise action anyone understands. Vaccinate CA was 'call a pharmacist, put the answer on a map so no one repeats the call.'
Pro tip A concise premise ('pick up phone, help save lives') also recruits volunteers and gives people agency.
- 2
Ship the crudest working version
Launch with the barest infrastructure — for Vaccinate CA, a spreadsheet and phones — rather than building the anticipated 'behemoth' first.
Pro tip Let the world's rate of change force you to prune scope rather than over-building because you can.
Watch out Having more resources tempts you to build more, which often shoots you in the foot.
- 3
Use the MVP to invalidate assumptions
Treat early operation as research: watch which of your assumptions about oversight, tooling, and data quality were wrong, then build the lighter-weight thing that actually works.
Pro tip Ask what you can prune — if you think you need to add more, you probably need less.
Watch out Assumptions about needing heavy oversight or bespoke tooling are frequently overturned by real usage.
In the wild
Vaccinate CA began as essentially a spreadsheet and volunteers on phones calling vaccine sites. Despite tiny infrastructure it had tremendous impact during the pandemic and revealed that the team's assumptions about needed oversight and tooling were wrong, letting them move faster as regulations shifted.
→ Saved lives with minimal tech and later grew into a national API feeding Google Maps, built on validated needs rather than guesses.
Common mistakes
Building the anticipated 'behemoth' up front
Constructing heavy infrastructure before validating needs wastes effort and slows adaptation; the crude version teaches you what's actually required.
Adding more because you have the resources
Extra headcount and budget tempt teams to over-build, which shoots them in the foot; the discipline is to prune.
Is it for you?
Best for
Founders and operators launching a new product or initiative, especially under fast-changing conditions or ambiguity about requirements.
Not ideal for
Regulated or safety-critical builds where a crude first version could cause direct harm without expert guardrails.
From the transcript
“the power of having like a laughably small MVP”
“in the beginning it was truly basically a spreadsheet on like phones and that was it”
“I was totally wrong about all my assumptions”
“that willingness to do just like the smallest possible thing”
“if you're thinking maybe you needed to add more stuff I bet you could prune”
From the episode
Lessons from Airtable’s unconventional growth strategy
Zoelle Egner