Scale in stages, fixing only what's actually breaking. From 100 to 1,000 users, add monitoring and backups. Up to 10,000, fix slow database queries, add caching and move slow work into background jobs. Towards 100,000, separate the database, run several app servers behind a load balancer, and invest in load testing. Most apps get there without a rewrite.
Founders often worry about scale too early, and engineers love to build for millions of users on day one. Both waste money. The usual reality is less dramatic: one slow query, one missing index or one job running inside a web request causes most of the pain. This playbook walks through what tends to break at each stage and the proportionate fix, as part of our wider guide to building a SaaS product from idea to paying customers.
What does "100,000 users" actually mean for your servers?
User count alone says little; what matters is how many people are active at the same moment and what they're doing. A B2B tool with 100,000 registered users might see a few hundred concurrently. A consumer app with live features might see thousands.
Before planning, estimate:
- Daily and peak concurrent users. Peaks matter more than averages: Monday mornings, month-end, a campaign launch.
- Heavy actions. Reports, exports, file uploads, search and anything that calls an AI model.
- Data growth. How many rows, files and events are added per user per month.
- Reads vs writes. Most apps read far more than they write, which makes caching powerful.
Scale the bottleneck you can measure, not the one you imagine.
Stage 1: How do you prepare at 100 to 1,000 users?
At this stage the job is visibility and safety, not performance. A single well-configured server and a managed database usually handle this comfortably.
Put these in place:
- Error tracking so you hear about crashes before customers email.
- Uptime and performance monitoring with alerts for slow pages and failed requests.
- Automated database backups, and one test restore so you know they work.
- Separate staging and production environments.
- Basic automated tests on the flows that make money: sign-up, login, payment, the core action. Our explainer on why skipping QA costs more later explains where to start.
- A CDN (content delivery network) for images, scripts and static files.
Also tidy the obvious waste. On grww.tech we cut portfolio image weight from 1.66 MB to 456 KB by converting to WebP and moved analytics to load after the page. Small fixes like these cost little and help every future stage.
Stage 2: What breaks between 1,000 and 10,000 users?
The database, almost always. Queries that were instant on a few thousand rows slow down on a few million.
Typical symptoms: dashboards that take several seconds, timeouts on reports, CPU spikes on the database.
Proportionate fixes:
- Find slow queries using your database's query logs or performance tools.
- Add indexes on the columns you filter and sort by most. This one step often solves the majority of problems.
- Fix "N+1" queries, where a page runs one query per item in a list instead of one query for the whole list.
- Paginate long lists and limit exports to background jobs.
- Cache expensive, frequently read results (pricing tables, dashboards, public pages) in memory with a tool such as Redis.
- Move slow work to background jobs. Emails, PDF generation, imports, image processing and third-party API calls shouldn't run while a user waits.
- Use connection pooling so the app doesn't open a new database connection for every request.
Stage 3: How do you get from 10,000 to 100,000 users?
Now you scale horizontally: several app servers behind a load balancer, a database that's sized and tuned on its own, and automation to manage it all.
- Stateless app servers. Store sessions and uploaded files outside the server (in the database, a cache or object storage) so any server can handle any request and you can add servers on demand.
- Load balancer in front, with health checks that remove unhealthy servers automatically.
- Database scaling. Upgrade to a larger managed instance, add read replicas for reporting-heavy features, and archive old data.
- Queues that can absorb spikes, with workers you can add when the backlog grows.
- Infrastructure as code so environments are reproducible rather than hand-configured.
- Load testing before big launches, simulating realistic peaks.
- Rate limits per user and per API key to stop one heavy customer slowing everyone down.
Proxies change how security works
Once a load balancer or CDN sits in front of your app, the app sees the proxy's IP address, and the visitor's real IP arrives in a header. That header can be faked unless you only trust it from your own proxy. We found exactly this on grww.tech: a login rate limit could be bypassed because the code trusted a spoofable IP header. We fixed it, and it's a common oversight when apps move behind a proxy. Every scaling change deserves a quick security review, not just a performance test.
What does each stage look like at a glance?
| Stage | What usually breaks | Proportionate fix | What to avoid |
|---|---|---|---|
| 100–1,000 users | Nothing yet; you're flying blind | Monitoring, backups, staging, CDN, core tests | Building for millions |
| 1,000–10,000 users | Slow queries, slow pages, timeouts | Indexes, query fixes, caching, background jobs, connection pooling | Rewriting in a new language |
| 10,000–100,000 users | Single server limits, traffic spikes, database load | Multiple stateless app servers, load balancer, read replicas, queues, load testing | Splitting into microservices by default |
| Beyond 100,000 | Specific hot spots | Extract the busiest component into its own service if needed | Big-bang re-architecture |
Do you need microservices to scale?
Usually not. A well-structured monolith (one codebase, deployed as one unit) with good database design, caching and background jobs can serve far beyond 100,000 users. Microservices solve team-coordination problems as much as technical ones, and they add operational overhead: more deployments, more monitoring, more network failures.
Extract a separate service only when one part of the system has clearly different needs, such as heavy video processing or a high-volume API. Our comparison of monolith vs microservices for small and mid-size businesses goes deeper.
How do you keep cloud costs under control?
Cost grows with scale, but waste grows faster. Review your bill monthly once you pass a few thousand active users.
- Right-size servers; many apps run on instances far bigger than they need.
- Use autoscaling so you pay for peak capacity only during peaks.
- Set storage lifecycle rules for old files and logs.
- Cache aggressively, since every cached response is a database query you didn't pay for.
- Watch third-party API costs, especially AI calls, which scale with usage.
- Set billing alerts so a runaway job doesn't surprise you.
Choosing between providers affects pricing, regions and managed services; see AWS vs Google Cloud for business software.
When is a rebuild genuinely necessary?
Only when the foundations prevent a fix: for example, a no-code platform with hard limits, no tenant separation in a multi-tenant SaaS, or a data model that can't support the product's core use. If the issues are slow queries and missing caches, fix those first. They're usually days of work, not months.
If you're planning a larger platform upgrade, GRWW's reference ranges put a mid-size web platform at about US$50k–150k over 4–9 months, depending on scope, with ongoing maintenance at roughly 15–25% of the build cost per year. Scaling work on an existing app is usually far smaller than that and best scoped after an audit.
Frequently asked questions
How many users can one server handle?
It depends entirely on what users do and how efficient the code is. A lean app on a single modern server with a managed database can often serve thousands of active users; a poorly optimised one can struggle with dozens. Measure with monitoring and load tests rather than relying on rules of thumb.
When should I add caching?
Add caching when monitoring shows the same expensive data being read repeatedly, such as dashboards, pricing or public pages. Fix slow queries first, because caching a bad query hides the problem. Plan how cached data is refreshed so users don't see stale information.
Do I need Kubernetes to scale?
Not for most business apps. Managed platforms, container services and autoscaling groups handle horizontal scaling with less complexity. Kubernetes makes sense when you run many services and have the team to operate it.
What's the first sign my app is hitting scaling limits?
Usually slower pages at peak times, timeouts on reports or exports, and rising database CPU. Customers mentioning slowness is a late signal; monitoring should catch it first. Check slow-query logs before buying bigger servers.
Can I scale a web app built by another agency?
Yes. Start with a code and infrastructure audit to find the real bottlenecks, then fix them in priority order. Most apps have a handful of high-impact issues rather than needing a rewrite.
Is your app starting to feel slow?
GRWW audits and scales web apps and SaaS products, fixing the bottlenecks that matter before suggesting anything bigger. See our services, or book a scaling audit and we'll show you where the time is going.