Systems-First Scaling (One to 100)
Once you have product-market fit, go slow to go fast: build the systems before you hyperscale.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 90%
Deng distinguishes zero-to-one (finding product-market fit) from one-to-100 (reaching hyperscale). In the scaling phase he rejects 'move fast and break things' in favor of planning chess moves ahead and building durable systems and the right information architecture — which then let the team move sustainably faster. Crucially, it's not a binary switch but a ramp rate governed by a portfolio approach.
Origin
Peter Deng's experience scaling Facebook News Feed, Messenger, and Uber's rider app through hyperscale.
Core principles
- 01Zero-to-one is finding fit; one-to-100 is reaching hyperscale as fast as sustainably possible
- 02Feeling the G-forces of a rocket takeoff is different from cruising — scaling requires different discipline
- 03Sometimes you have to go slow to go fast; systems thinking carries you far
- 04The switch to systems investment is a ramp rate, not a binary — allocate via a portfolio approach
How to run it
- 1
Recognize you've crossed into one-to-100
Once product-market fit is found and you're pushing for hyperscale, change posture from MVP experimentation to forethought.
Watch out Carrying 'move fast and break things' into hyperscale leaves you with a spaghetti-code situation that caps growth.
- 2
Plan your chess moves in advance
Think several moves ahead about the whole flow and its information architecture before acting.
Pro tip Study the entire loop — e.g. posting, News Feed appearance, likes, the red notification — and architect it to last.
- 3
Find the right abstractions and build the systems
Rearchitect around core components and the right abstraction (e.g. Uber's 'venues' abstraction for pickups/drop-offs) so the product scales globally.
Pro tip Unglamorous infrastructure (pickup/drop-off, push notifications) is often the load-bearing work that unlocks scale.
- 4
Ramp investment via a portfolio
Don't flip a binary switch; decide how much time to allocate to systems vs new bets based on stage (e.g. Google's 70/20/10 for a mature company, closer to 50/50 for a startup).
In the wild
Deng notes that in countries like India there are often no street signs, so a whole team worked on pickups/drop-offs. Finding the right 'venue' abstraction made pickups scalable across airports and configurable venues worldwide — 'it sounds so boring but it was so critical.'
→ The systems built in the one-to-100 phase helped Uber's rider product achieve 4x users in two years.
On Messenger, the team invested heavily in the infrastructure around push notifications rather than shipping quick features.
→ The product grew from zero to 4.7 billion messages sent per day in about two and a half years.
Common mistakes
Carrying MVP speed into the scaling phase
Uber's rider app hit a 'spaghetti string code situation' because scaling was attempted without stepping back to rearchitect core components — forcing a costly rebuild before it could scale globally.
Treating the systems investment as a binary switch
Deng warns it's a ramp rate, not on/off; over- or under-investing at the wrong stage (ignoring the appropriate portfolio split for your maturity) misallocates scarce time.
Is it for you?
Best for
Product leaders and founders who have found product-market fit and are entering hyperscale
Not ideal for
Pre-PMF teams who should still be experimenting cheaply rather than over-building systems
From the transcript
“you have to plan your chess moves out in advance.”
“And sometimes you have to go slow to go fast.”
“those systems when you take the time to build them in the one to 100 phase help you speed up massively”
“It's actually a ramp rate.”
From the episode
From ChatGPT to Instagram to Uber: The quiet architect behind the world’s most popular products
Peter Deng