How Problems Scale

Every problem has a cost that grows as you do more of it. Understanding how that cost grows is one of the most important questions you can ask.

The Four Types of Scaling

When you go from 1 to 10 to 100 units (users, tasks, servers, emails), the time or resources required can grow in different ways:

Sublinear — Cost grows slower than volume

• 1 user: 10 hours → 10 users: 50 hours → 100 users: 200 hours
• This is ideal. You're getting more efficient as you scale.

Linear — Cost grows proportionally

• 1 user: 10 hours → 10 users: 100 hours → 100 users: 1,000 hours
• This is manageable. Predictable and plannable.

Superlinear — Cost grows faster than volume

• 1 user: 10 hours → 10 users: 150 hours → 100 users: 5,000 hours
• This is dangerous. It will eventually consume you.

Exponential — Cost explodes with volume

• 1 user: 10 hours → 10 users: 10,000 hours → 100 users: 1,000,000 hours
• This doesn't scale. Fix it or it breaks you.

The Goal Is Awareness, Not Perfection

This isn't about making everything sublinear. That's often impossible or wasteful.

The goal is to be conscious of how things scale so you can make informed trade-offs:

• Sometimes linear is fine—you just need to know it's linear and plan accordingly
• Sometimes you accept superlinear scaling because fixing it would take longer than living with it
• Sometimes you over-optimize too early and waste more time than the problem would have cost

The questions that matter:

• How does this scale?
• To what point does it need to scale?
• What breaks first when we grow?
• Is fixing this now worth it, or should we wait?

Know Your Triggers and Change Costs

Two critical questions determine when and how to act:

Triggers: When do you need to change?

Define the signal that tells you "now we need to address this." Not vague discomfort—concrete metrics:

• Manual onboarding takes more than 20 hours per week
• Database queries exceed 2 seconds
• Support backlog grows beyond 50 tickets
• The team spends more than 10% of time on this problem

Set triggers based on impact and change cost. Monitor them. When you hit the trigger, act.

Change Cost: How expensive is it to adapt?

When you do need to change, what's the cost to tear down and rebuild?

• How much code needs rewriting?
• How many processes need redesigning?
• How much institutional knowledge becomes obsolete?
• How many integrations break?

Low change cost means you can wait longer and adapt quickly. High change cost means you need to act earlier—or build differently next time.

The relationship: If your change cost is low (loosely coupled, standardized), you can set triggers later and move fast when needed. If your change cost is high (tightly coupled, custom), you need earlier triggers or you'll be locked in.

Build for Change, Not Forever

You can't predict the future. Requirements change. The company pivots. What seemed critical becomes irrelevant.

So build things that are:

• Loosely coupled — parts can change independently
• Highly standardized — predictable patterns, not one-offs
• Very adaptive — easy to modify when the world shifts

This keeps your change cost low. Don't build for infinite scale. Build for the scale you need, plus one order of magnitude. Build for change.

Examples in Practice

In operations: Manually onboarding customers is linear. Trigger: When it takes more than one person full-time. Change cost: Low if you documented the process; high if it's all tribal knowledge. Act accordingly.

In code: A nested loop over 100 items might be O(n²) but fast enough. Trigger: When it takes >1 second or you hit 10,000 items. Change cost: Low if the function is isolated; high if it's tangled throughout the codebase.

In communication: Five people can chat freely. Trigger: When people start missing important information or meetings feel chaotic. Change cost: Low if you introduce simple protocols; high if you need to restructure teams.

The Questions to Always Ask

"How does this scale, and does it need to?" "What's my trigger to change it?" "What's the cost to change it when I need to?"

If you can't answer these, measure. If it will break at your target scale, decide: act now or set a trigger. If the change cost is high, consider rebuilding for adaptability.

Your goal isn't to make everything perfect. It's to know what you're accepting, what you're monitoring, and what you're fixing—and why.

---

Once you see scaling, you see it everywhere. The power isn't in always optimizing—it's in always knowing.

---

Christian Blank
San Francisco · Updated May 2026
christian@blank.dev | www.blank.dev
Co-written and formatted with AI