What does scalability mean when developing an app?

Growth reveals weaknesses that were previously invisible

Sometimes the moment comes gradually: The app feels “a little” slower, support tickets pile up, and release days become tense.

And sometimes it comes with a bang. A campaign takes off, a mention in the press brings a peak, or your purpose-driven project gets shared in a newsletter. 500 daily users become 50,000 – not over a year, but over a weekend.

In our projects, we see: Scalability rarely becomes important out of love for technology, but rather out of love for trust. Because when an app wobbles under load, it’s not just “an error” that happens. Something happens in people’s minds: People drop off, ratings take a hit, and teams go into crisis mode.

The expectations are brutally honest. Even with mobile web experiences, it becomes clear how little patience there is: Over 53 percent leave a page if it takes longer than three seconds to load. Marketing Dive (Google-Studie, 2016)↗

Even though apps are not one-to-one equivalents of websites – the emotional logic is the same: “If it doesn’t work immediately, it’s not reliable.”

Our first fresh perspective: Scalability is also impact reliability. If you are building an educational app that is meant to reach more people, or a platform that gets donations moving, then stability is not just a technical issue. It is part of your responsibility: Your mission must not fail because of an overloaded login endpoint.

That’s why at Pola we start early with a simple but crucial question: What does your app need to be prepared for – predictable growth, unpredictable peaks, or both? This distinction later determines whether you primarily prioritize capacity, elasticity, or robustness.

User load and product complexity grow independently of each other

When someone says “We need to build the app to be scalable”, they often just mean: “More users should be able to get in at the same time.” That’s important – but it’s only half the story.

Scalability has two growth axes:

First: Load growth. More simultaneous requests, more traffic, more devices, more background jobs for your system (push, sync, uploads). The app market continues to grow, and with it the expectation that everything simply works. The sheer density alone shows the pressure: in 2023 there were over 3.7 million apps in the Google Play Store and around 1.8 million in the Apple App Store. Selleo↗

Second: Feature growth. New features, new roles, new integrations, new markets. An app that started with 5 screens becomes a product with rules, special cases and exceptions over time. And this is exactly where many things tip over: Not because the CPU is too weak, but because every change suddenly becomes risky.

The distinction is important: Scalability is not the same as performance. Performance describes how fast something is under a given load. Scalability describes how well the app maintains its performance as the load increases.

An everyday analogy we like to use: Performance is how fast a train travels on a clear track. Scalability is whether the timetable still works when suddenly three times as many people get on – without doors jamming, signals failing or the entire operation coming to a standstill.

Our second fresh perspective: Scalability is team-friendly architecture. In practice, it’s not just the app that grows, but also the team working on it. If several developers are supposed to deliver in parallel, you need structures that decouple changes from one another. A “scalable app” therefore also means: easy to test, modular, understandable.

If you name these two axes early, decisions become easier: Some projects first need load reserves, others first need a clean foundation for feature growth. And often it’s a mix – but with clear weighting.

Four questions make reserves concrete

Scalability quickly becomes a gut feeling when nobody defines what makes “enough” recognizable. We therefore try to put the topic into a form early on that holds up in everyday work.

We call our field-tested method internally the Four-Question Test. It is deliberately simple so that it doesn’t get lost in the project:

1) What is your critical moment? For example: registration, checkout, donation completion, data upload.

2) What does “critical” mean in numbers? For example: 500 simultaneous sessions or 50 requests per second – with a target for response times.

3) What may it cost? Not only in monetary terms, but also in terms of operational complexity.

4) What happens if things go wrong? Loss of revenue, loss of trust, missed impact.

That brings us to metrics you can monitor without drowning in numbers: Latency (response time, preferably as the 95th percentile), Throughput (requests per second), Error rate (time-outs, 5xx, crash rates) and Cost per request.

Why costs too? Because otherwise scaling can become secretly expensive. Good scalability does not mean „more and more servers“, but more performance per resource deployed. This is exactly where an often-overlooked ROI lies: A more efficient app saves cloud costs and simultaneously reduces energy consumption.

For the economic side, a reality check helps: Even small delays can be costly. Amazon observed internally that an additional 100 milliseconds of delay can affect revenue by 1 percent. LinkedIn Post (Amazon-Zitat, weiterverbreitet)↗

We do not use figures like these to create pressure, but to clarify the priority: If your critical moment is conversion, then scalability is not a „tech extra“, but protection of your value creation.

And one more thing that makes the difference in practice: Measurability is also reassurance. If you have monitoring and load tests, you do not have to hope. You can know.

A peak always hits the narrowest part

When apps break „under load“, from the outside it often looks like a single problem: „Server overloaded.“ In reality, it is almost always a chain of bottlenecks.

The classic one is the database. At first, it is convenient: one central place, everything consistent, everything traceable. And then comes the moment when a single query suddenly runs a thousand times more often. Or a lock blocks write operations. Or a poorly chosen index turns a search into a full-text crawl.

Just as frequently, it is the code. Not „programmed too slowly“, but too tightly coupled. One function calls three others, waits for an external API and writes logs synchronously on the side. That works with 50 users. With 5,000, it becomes a domino effect.

And then there is the bottleneck that hardly anyone talks about first: Processes and releases. If a hotfix can only be deployed at night, when deployments are scary, when nobody knows exactly what needs to be monitored after the release – then it’s not the system that scales, but the stress level.

Our third fresh perspective: Scalability is incident-friendliness. We don’t just build for “more”, we build for “when something goes wrong”. That’s a subtle difference: A robust app has clear boundaries, clear timeouts, clear fallbacks. And it helps the team quickly understand what’s happening.

In practice, we like to use a small principle for this that you can take away immediately: “Keep the critical part short.” Everything that is your critical moment (registration, checkout, donation) should have as few dependencies as possible. If you still want to send emails, generate PDFs or update statistics afterward, do it asynchronously.

This also shows why many outages are so costly: Downtime is not just a technical state, but a business loss. Atlassian cites examples in which outages at large companies caused damages in the tens of millions. Atlassian↗

You don’t have to be Facebook to feel this effect. Smaller products simply have less buffer.

More power and more instances solve different problems

When we talk about scaling, we quickly arrive at two basic models: vertical and horizontal.

Vertical means: You give a system more power. More CPU, more RAM, a larger database setup. This is often the first step because it works quickly and requires little restructuring. But vertical scaling has limits: at some point it becomes very expensive, and you still have a central point that can fail.

Horizontal means: You distribute the load across multiple instances. Not one stronger server, but several – ideally so that you can automatically scale up during peaks and scale back down during quiet periods.

For horizontal scaling to work, you usually need two things: a Load Balancer (which distributes the traffic) and services that are stateless . This sounds technical, but it’s easy to understand: If a user login only works on server A because the session is stored there, then server B can’t help. If the state, on the other hand, is stored in a shared store (e.g. in a database or a cache like Redis), any instance can step in.

In practice, scaling is often a mix: A little vertical scaling to quickly get some breathing room, and targeted horizontal scaling where it really matters.

What we always keep in mind: Reliability is a sibling of scalability. As soon as you work horizontally, you often automatically build in redundancy. If one instance fails, others take over. That’s not just “more performance”, but less risk.

And this is where our Pola perspective comes in: We don’t like “constant maximum performance”. It becomes sustainable when your system is elastic. Additional resources only when they are needed. That saves costs and avoids unnecessary energy consumption – the technical side of an attitude: don’t waste.

If you’re just getting started, the most important decision therefore isn’t “Kubernetes or not”, but: Can your app fundamentally handle multiple instances? If you prepare this properly, many paths remain open to you.

The simplest viable path is often the best

The architecture question is often discussed unnecessarily ideologically: monolith bad, microservices good. We see it differently. For many products, a well-built monolith is exactly right at the beginning: faster to implement, easier to test, easier to understand.

The problem is rarely the monolith itself, but a monolith without boundaries. If everything knows everything, every change becomes expensive.

That’s why we like to use a second tried-and-tested method: “Cut by responsibility, not by technology.” Concretely, this means: We structure things early according to business domains, so that you can later extract individual parts without tearing the whole product apart.

A typical path looks like this:

• Start as a modular monolith with clear domains (e.g. accounts, content, payments).
• When a domain grows significantly or develops special requirements, it is extracted as its own service.
• Only when teams and operations genuinely benefit from it do multiple independent services emerge.

Why this order? Because microservices do allow you to operate parts independently, but they bring new tasks with them: network communication, distributed debugging, versioning, observability. This is worthwhile when complexity is already there – not to “buy” complexity.

This is also where an important warning from the startup context fits: There are indications that a large proportion of startup failures are related to scaling too early – often organizationally and strategically, but the idea is transferable. LinkedIn Post (Startup Genome Zahl, weiterverbreitet)↗

Our stance on this: Plan the door, don’t build the whole house right away. An app can start as an MVP. But it should be built in such a way that you don’t have to start over with every step of growth.

If you want to dive deeper into decisions like these: We have also supported similar architecture questions in app projects, for example where new features and user groups were added later (e.g. Ureka or Aeri). The context is different every time – the principle remains: clarity before size.

Caching and decoupling create targeted reserves

When we pragmatically improve scalable apps, we rarely start with “big” overhauls. Usually, a few targeted building blocks immediately bring stability – and they also fit a sustainable mindset because they reduce resource waste.

Caching is often the first. If 10,000 people open the same homepage, your system shouldn’t do the same work 10,000 times. A cache (for example Redis) stores frequently used data in memory and relieves the database and backend.

CDNs are the second classic. Images, assets, and sometimes even parts of API responses can be delivered closer to the user. This lowers latency and reduces load on the core system. For many teams, Cloudflare is a quick starting point because you can combine CDN, caching, and protection features well.

Queues are our favorite building block when peaks are unpredictable. Instead of trying to handle everything immediately, you accept tasks and process them in the background. This smooths out load spikes and makes your system more “patient”. Technically, this can be done with RabbitMQ or – on a larger scale – with Apache Kafka .

And then there are the database strategies: replication for more read performance, clean indexes, sometimes partitioning. This is less glamorous than microservices, but often the point where something really starts to move.

The order is not dogma, but rather an observation: First make the obvious things efficient, then distribute.

Our fresh perspective on this: Green growth is often simply good engineering. An architecture that only scales up when needed is usually cheaper – and it consumes less energy than a system that runs permanently at maximum size. Scand also describes scalability as resource efficiency: resources are only added as load increases. Scand↗

If you work with a purpose-driven approach, this is a quiet but important point: Your product can grow without your operations “growing along with it” like a constant blaze.

Without tests, resilience remains only an assumption

Scalability doesn’t only emerge during building, but above all during operation. We have seen too often that teams were “actually” well set up – and then exactly what would have made the peak controllable was missing: a test, an alert, a clear routine.

Load tests sound like a luxury. In reality, they are often the cheapest reality check you can get. Miquido puts it pragmatically: Whether an app can grow only becomes apparent through load and performance tests. Miquido↗

If you’re looking for a tool that fits well into modern pipelines, we like k6 a lot: script-based, easy to automate, clear output. For more traditional setups, JMeter or Gatling are also solid.

Monitoring is the second part of the equation. Not just “CPU is high”, but: Which endpoints are getting slow? Which DB queries dominate? Where are error rates rising? For that, you need observability – metrics, logs and (in distributed systems) traces. A proven open-source duo is Prometheus plus Grafana. If you want to get up and running faster, tools like Datadog or New Relic are often pragmatic.

And then comes incident readiness: What happens when things really catch fire?

We like to keep it simple and practice three things with teams:

1) A release needs observation. Which metrics do we check in the first 30 minutes?

2) Alerts need to be actionable. Better a few that are right than many that get ignored.

3) Rollback is a feature. If rolling back is difficult, every update becomes risky.

What this has to do with Pola: Our work doesn’t end at launch. We think about performance, maintainability and operations together – because scalability is only real when it brings peace of mind in everyday life. And in the end, peace of mind is a quality characteristic that users feel without being able to name it.