When we talk about scalability in technology, the conversation quickly moves toward infrastructure. How many requests can we handle? Do we have autoscaling? Can we add more servers? Can the database keep up? These are important questions. And there's an important distinction: scaling compute is often relatively straightforward; state — and the database in particular — can still be one of the difficult parts.
But even if we solve that dimension perfectly, we still don't know whether the company can scale. Handling more traffic and scaling a business are two different problems.
Suppose We Sell Ten Times More Tomorrow
Imagine a company that processes 10,000 applications per month today and, after extraordinary growth, reaches 100,000. The infrastructure performs well. The application remains available and technical response times stay within expected ranges.
Has the company scaled?
We still don't know.
We need to understand what happened to exceptions, customer support, fraud, reconciliations, operations, security, data, and the teams keeping everything running. Because if sales increase tenfold but we also need ten times as many people to support them, technically we handled more volume.
Economically, we may not have scaled at all.
That's the distinction that matters most to me.
Growth Becomes a Problem When It Turns Into Manual Work
Systems tend to work well while everything follows the expected path. The challenge begins with exceptions: an application that couldn't be processed, a payment that didn't reconcile, a document that couldn't be validated, or an integration that returned something unexpected.
And then a person appears.
When we have one hundred cases and two require manual intervention, it may not matter much. But if we grow the business tenfold and those exceptions grow with it, one person can become five, five can become twenty, and eventually an entire team may be dedicated to compensating for what the system couldn't handle.
To me, that's a very clear signal:
When growth systematically moves work from systems to people, it's time to revisit the design.
That doesn't mean all human intervention is bad. Some decisions require context, judgment, or a level of risk that makes human involvement entirely reasonable. The goal shouldn't be to remove humans from the process. It should be to reserve human intervention for the situations where human judgment actually creates value.
Scaling Means Creating Leverage
Consider a fintech company managing a credit portfolio.
Suppose it grows sales tenfold.
If managing a portfolio ten times larger also requires an operations team ten times larger, there's an almost linear relationship between business volume and organizational structure. Now imagine the company sells ten times more, processes ten times more applications, and manages a portfolio ten times larger while the amount of work required from its teams grows only marginally.
Something different is happening.
Technology is creating leverage.
That's how I like to think about scalability:
A company scales when its ability to generate business grows much faster than the resources required to support it.
That doesn't mean headcount should never grow. It means volume and organizational structure shouldn't be forced to grow at the same rate.
Unit Cost Tells a Better Story
A practical way to analyze this is to stop looking only at total cost and start looking at cost per unit of business. Suppose we currently process 100,000 applications per month. Between infrastructure and human operations, each application costs us USD 0.50:
- USD 0.15 in technology;
- USD 0.35 in operational work.
That's approximately USD 50,000 per month. Now the business grows tenfold and processes one million applications. If there's real leverage, some fixed costs are now spread across much more volume. Perhaps unit cost drops to USD 0.30. The business grew 10×, while the associated cost increased from USD 50,000 to USD 300,000: a 6× increase.
That could be a very positive signal. Now consider the opposite scenario. Exceptions increase, we need more people, new manual processes appear, and the cost per application rises to USD 0.70. One million applications now cost USD 700,000 per month.
The business grew.
But every additional unit of business became more expensive to produce. FinOps' Unit Economics capability addresses exactly this idea: connecting technology spending with the value generated by the organization's products, services, or activities instead of analyzing technology spending in isolation.
A larger cloud bill doesn't necessarily mean there's a problem. It may simply mean the business is growing.
The more relevant question is:
What happens to the cost required to produce each additional unit of business as we scale?
Leverage Also Creates Risk
We should avoid treating automation as an objective in itself. Suppose we automate every exception in a credit origination process. We remove most manual intervention and significantly reduce operating costs.
Great.
But now an incorrect decision can also be executed automatically thousands of times. A false fraud positive can block legitimate customers. A faulty rule can reject valid applications. A reconciliation error can propagate before anyone notices. The person who previously handled the exception wasn't only a cost.
In some cases, that person was also a control. So the question shouldn't only be how much we can automate. We also need to measure error rates, the potential impact of incorrect decisions, monitoring mechanisms, and the conditions under which an operation should be escalated back to a person.
Scaling doesn't mean removing controls. It means designing controls for the new scale.
Automating a Bad Process Only Makes It Faster
We could try to solve every problem through automation. But automation doesn't guarantee scalability. If we automate a poorly designed process, we may simply execute a bad process faster. DORA uses a similar idea when analyzing the adoption of AI in software development. Its State of AI-assisted Software Development 2025, based on nearly 5,000 technology professionals, describes AI as an amplifier: it can strengthen organizations with good capabilities while also amplifying existing problems.
The research found improvements in delivery throughput, but also increased instability. My extension of that idea is simple:
technology amplifies systems.
Before automating a process, we should understand what system we're about to amplify.
The Dimensions We Often Forget
Infrastructure is only one part of scalability. At least two other dimensions often become visible only after the business has already grown.
Data
With a small number of customers, we can survive with scattered information, manual processes, ambiguous definitions, or knowledge stored in specific people's heads. At ten times the operational volume, that starts to break. We need to measure, audit, detect anomalies, automate decisions, build models, and understand what is happening.
To do that, we need to have designed how data is captured, stored, governed, and made accessible. A company can have scalable infrastructure and a data architecture that doesn't scale.
Organization
The same is true for people.
A team of five developers may coordinate by talking. A team of fifty needs different mechanisms: ownership, documentation, standards, observability, development processes, internal platforms, and ways to share knowledge. DORA reported in 2025 that 90% of surveyed organizations had adopted internal platforms, while 76% had dedicated platform teams.
That doesn't mean every startup should build a Platform Engineering team tomorrow. It means that practices that work for ten people don't necessarily work for one hundred. There's another important constraint: hiring doesn't scale instantly either. A new employee may need weeks or months to reach full productivity. Some profiles are scarce, and critical knowledge concentrated in two people can't simply be multiplied by approving more budget.
Human scalability isn't only about how much hiring costs. It's also about how quickly an organization can absorb new people and how effectively it can transfer knowledge without depending on specific individuals.
The 10× Test
There's an extremely simple question I like to use:
If the business grew tenfold tomorrow, what else would have to grow tenfold?
The answer works almost like a diagnostic. If we need more compute capacity, we can probably solve it — although, again, state and databases deserve special attention. But if we also need ten times the operations team, manual exceptions, incidents, fraud handling, response times, or transaction costs, then there's something we need to examine.
Not everything needs to remain constant. That would be unrealistic. The question is which variables are growing linearly with the business and whether they actually should. We can run the test across five dimensions:
- Technology: what infrastructure needs to grow?
- Cost: what happens to unit cost?
- People: which teams need to grow, and by how much?
- Processes: which manual tasks and exceptions multiply?
- Risk: which errors or incidents become more consequential at scale?
The list produced by those five questions tells us much more about our ability to scale than knowing how many requests per second an API can handle.
Scaling Is Not About Handling More Traffic
That's why I wouldn't define scalability as the ability to support more users or more requests.
I'd define it differently:
Scalability is the ability to grow the business significantly without increasing the complexity, cost, and effort required to support it at the same rate.
That includes infrastructure, but also architecture, processes, data, security, people, and culture. And it changes the question a CTO should be asking.
It's no longer only:
“Could our systems handle ten times more users?”
It's:
“Could our company operate with ten times more users?”
The difference may seem small.
But it can be the difference between a company that's simply growing and one that's actually ready to scale.