Scale - Mental Model: Imagine the Future
Understand scale before it breaks.
The app is working for 10 users, so it should handle a few thousand users, right?
One of our clients didn’t know anything about scaling software. He set up a marketing campaign with famous influencers to promote the app. We had no idea what was coming. A huge spike in traffic overwhelmed the prototype for hours until the team was able to scale it. Talking about scale would have saved us.
Scale is a mental model from the domain of systems thinking that reminds us:
Size matters.
What works at a smaller size often breaks when growing. What works for big teams will suffocate small ones with formalisation. It’s about understanding how systems behave when shrinking and growing.
Questions to ask: How does it scale? What breaks down first?
The lens of scale
The scaling problem can be observed at many levels. From scaling software and companies, to managing teams and your time.
Thought experiments
Thought experiments help you think through scaling challenges before they happen.
Acknowledging it is the very first step. Each system scales differently, but this simple exercise works everywhere:
Take a piece of paper and write down answers to these questions:
What happens when the system grows 10x? 100x? 1,000x?
What if it shrinks to 20% of its current size?
Example: You have a 5-person team that communicates informally on one Slack channel. At 50 people, informal chats create confusion. You need to establish communication rules, decision-making frameworks, etc. Then, at 500 people, you need completely different structures.
Thinking on paper helps you visualise what actions you’ll need to scale your solutions or change when it shrinks.
Simply sitting with pen and paper, imagining the future, plants seeds for preparation. I’m a huge advocate for writing as a distillation of thinking. In every case, not just for scaling thought experiments.
Premature optimisation
Not every app will become the next Instagram or TikTok. Not every business will hire thousands of people.
Founders tend to be optimistic, but it’s good to apply common sense. I’ve worked with dozens of startups building their first MVPs, and every single one believed they’d scale to millions of users quickly, but unfortunately, optimism doesn’t imply success. Most of them disappeared a few months later.
Examples of scaling too early:
Hiring too fast just to show growth numbers
Setting up infrastructure for thousands of users when you have dozens
Over-engineering for problems you don’t have yet
But always ask about plans and act accordingly. One day, they might launch a marketing campaign you didn’t know about.
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
— Donald Knuth
(Often, only the bold section is used, while the full quote shares great wisdom)
Summary
Scaling is an essential aspect of every system. It’s about thinking through what breaks before it happens.
Run the thought experiment before the influencer campaign goes live. You don’t want your users to discover the limits for you.
How do you think about scale?
Thanks for reading!
— Michał
Post Notes
Discover Weekly — Shoutouts
Great articles which I’ve read recently:
Cursor Commands, Claude Code Skills, Hooks, MCPs: Essentials or Overkill? By
Stop asking for feedback. Start asking for action by
Coding at work (after a decade away) by Will Larson
Connect
LinkedIn | Substack DM | Mentoring | X | Bsky






I’m glad you quoted Knuth properly:
“[…] Yet we should not pass up our opportunities in that critical 3%.“
As you said very well the full quote shared great wisdom.