The Scale Fallacy

Nowadays, whenever we start a software project, we fall into the same discussion: what scale does this software need to handle?

And that’s where the problem begins. As good engineers, we try to predict all the situations the system could face. Even without taking a single step yet, we’re already thinking about:

• distributed architecture on day one,

• layers and layers of folders and modules to “ensure decoupling”,

• using the same NoSQL database that giant companies use,

• copying practices that only make sense in companies with hundreds of millions of users.

Throughout my entire career it was always the same:

“how many users?”,

“how many transactions per second?”,

“how many emails?”,

“how much traffic?“.

And the higher the position of whoever answered, the more absurd the number and the more megalomaniacal the project became. This puts any developer in a state of permanent anxiety: too many domains, too many services, too many integrations, too many decisions based on fear and not on facts.

The reality is simple:

in most companies, no one knows if the product will survive long enough to have a scale problem.

If you’re at a startup with three clients and cash for four months, scale doesn’t matter, what matters is launching fast, getting feedback fast, and iterating fast. You don’t even know yet if you’ll reach the point where scale becomes a real problem.

Now… If you’re at Nubank, Google, Meta, etc., that’s a different universe. The expectation is born in “millions”. Architecture, budget, roadmap, and technical decisions are already thought through for that from the top of the chain. It’s aligned with CEO, investors, board, everyone.

But that’s 0.001% of cases.

In most companies I’ve been through or talked to people who’ve been through, technical decisions are made like this:

feeling > data assumption > metrics fear > reality

And when that happens, aberrations emerge. Software that costs millions, takes years to develop, is never used, and then simply discarded. I’ve lived this: I joined a company that had 191 nanoservices created by six devs, four years of work, zero use in production, and in the end they threw everything away and went back to the legacy system that always paid the bills.

The problem isn’t using advanced tools.

The problem is using them because “it seems right”.

That’s the central point of the Scale Fallacy:

most decisions about “scale” are made without any real data.

People imagine bottlenecks that may never exist. They anticipate 30 years of problems for a product that barely started.

And this generates loss, delay, and totally unnecessary complexity.

So what’s the right path, then?

There’s no formula, but there is a method.

Understand the context of the company you’re in

If you work somewhere that doesn’t have a realistic expectation of reaching millions of users, you don’t need to write code as if you were at Google. It’s a different game, a different reality, a different goal.

Build the minimum necessary

A lean, simple, straight-to-the-point system. No frills, no premature abstraction, no ornamental engineering.

Make the system flexible and easy to change

Extensible, loosely coupled, easy to iterate. The concern isn’t predicting the entire future; the concern is ensuring that when the future arrives, you can adapt without suffering.

Observability from the first deploy

With metrics, logs, traces, and real numbers, you know:

• when the database is struggling,

• when an endpoint is slow,

• when queues start to accumulate,

• when you really need to scale.

Without data, you guess. With data, you adjust.

That’s what separates responsible engineering from fantasy-based engineering.

In the next posts

I’ll dive into the individual biases that feed this fallacy, such as:

• “relational databases don’t scale”

• “monoliths don’t scale”

• “microservices from day 1”

• infinite layers “to decouple”

• hype-driven development

• copying big tech without reason

And especially: how to make technical decisions based on reality, not paranoia.