Scale From 100 to 10,000 Users Without Everything Breaking

A founder called me in a panic. "Our app just went down. We hit 500 concurrent users and everything crashed."

"Did you have monitoring set up?" I asked.

"No, we were focused on features."

"Database indexes?"

"What are those?"

"Caching?"

"We thought we'd add that later."

They had 1,200 users and were still running the same architecture they launched with at 10 users. Pages that loaded in 200ms were now taking 8 seconds. Background jobs were piling up. Users were leaving.

This is the scaling trap: your MVP was built to prove an idea, not handle thousands of users. The code that got you from 0 to 100 breaks at 1,000. But here's the good news—you don't need to rebuild everything. You need to know what to fix, when to fix it, and what to leave alone.

The Three Growth Phases (And What Breaks at Each)

Scaling doesn't happen gradually. It happens in jumps. Here's what typically breaks:

Phase 1: 0-100 Users (Weeks 1-8)

What's happening: Early adopters. Tolerant of bugs. You're learning what features matter.

What usually breaks:

• Nothing major (if you built your MVP right)
• Small bugs and edge cases
• User confusion about features

What to focus on:

• Fix critical bugs immediately
• Improve onboarding based on feedback
• Understand which features users actually use
• Add basic analytics if you haven't already

What NOT to worry about: Performance optimization, scaling infrastructure, perfect code.

Phase 2: 100-1,000 Users (Months 2-6)

What's happening: Past early adopters. Real users with real expectations. Growth accelerating.

What usually breaks:

• Database queries slow down (pages that loaded in 200ms now take 3+ seconds)
• Background jobs pile up (emails delay, processing lags)
• Support workload explodes (can't manually help everyone)
• API rate limits hit (third-party services throttle you)

What I help founders fix:

1. Add database indexes: This fixes 80% of performance issues. Find slow queries, add indexes.
2. Implement caching: Cache expensive database queries, API calls, rendered pages.
3. Move long tasks to background jobs: Email sending, report generation, data processing.
4. Add monitoring: Error tracking (Sentry), performance monitoring (DataDog/New Relic), uptime checks.
5. Improve documentation: FAQ, help docs, video tutorials—reduce support burden.

Phase 3: 1,000-10,000 Users (Months 6-12)

What's happening: You're a real product. Users expect reliability. Downtime costs revenue.

What usually breaks:

• Single server can't handle load (CPU/memory maxed out)
• Database becomes bottleneck (write conflicts, connection pool exhaustion)
• File uploads slow everything (user content clogs your server)
• Deploys break things (monolith becomes unwieldy)

What we fix:

1. Scale horizontally: Multiple servers behind load balancer
2. Database read replicas: Separate reads from writes
3. Move files to object storage: S3, Cloudflare R2
4. Add queueing system: Redis/Sidekiq, RabbitMQ for background jobs
5. Automated testing: Integration tests for critical workflows

What to Optimize (And When)

Most founders optimize too early or too late. Here's when to act:

Priority 1: Database Optimization (Fix This First)

90% of performance problems are database problems. Here's what I do with founders:

Add indexes to slow queries:

I run query analysis to find which queries scan millions of rows. Add indexes. Watch queries drop from 3 seconds to 50ms.

Add pagination:

Never load 10,000 records. Load 20 at a time. Infinite scroll or "Load More" buttons.

Connection pooling:

Reuse database connections instead of creating new ones for every request. This alone can handle 5-10x more users.

Priority 2: Caching (Biggest Impact for Lowest Effort)

Caching makes expensive operations cheap. I implement caching at multiple levels:

• Application-level: Redis for database query results (5-60 minute TTL)
• HTTP-level: CDN (Cloudflare) for static assets and pages
• Browser-level: Cache-Control headers for client-side caching

What we cache:

• Database queries that don't change often (user profiles, settings)
• API responses from third parties
• Expensive calculations (reports, analytics dashboards)
• Rendered HTML fragments

Result: 5-10x faster page loads for $20-50/month.

Priority 3: Background Jobs (Keep UI Responsive)

Never make users wait for slow operations. We move them to background jobs:

• Sending emails (was: 3 seconds per request, now: instant response)
• Generating PDFs or reports (was: 5+ seconds, now: background)
• Processing uploads (was: blocking, now: async)
• Third-party API calls (was: variable delays, now: background)

Tools I use: Sidekiq (Ruby), Celery (Python), Bull (Node.js).

Priority 4: Infrastructure Scaling (When You Hit Limits)

Signs you need to scale infrastructure:

• CPU consistently >80%
• Memory consistently >90%
• Response times >2 seconds even with optimizations

Scaling options I recommend (in order):

1. Vertical scaling: Upgrade to bigger server (easiest, works to ~5K users)
2. Horizontal scaling: Multiple servers + load balancer (more complex, handles 10K+ users)
3. Specialized services: Separate workloads (most complex, most flexible)

Monitoring: Know When Things Break Before Users Tell You

You can't fix what you can't see. Here's what I set up for founders:

Layer 1: Error Tracking (Essential)

Tool: Sentry, Rollbar, or Bugsnag

What we track:

• Unhandled exceptions and crashes
• Failed API calls
• Database errors
• Failed background jobs

Setup: Alerts when errors spike or critical paths fail. You find out about problems before users complain.

Layer 2: Performance Monitoring (Important)

Tool: New Relic, DataDog, or Scout APM

What we track:

• Response times (p50, p95, p99 percentiles)
• Database query times
• API endpoint performance
• Background job duration

Setup: Alert when p95 response time >2 seconds or database queries >500ms.

Layer 3: Uptime Monitoring (Critical)

Tool: UptimeRobot (free tier works great), Pingdom, or StatusCake

What we monitor:

• Homepage loads successfully
• Login flow works
• API endpoints respond
• Critical user workflows complete

Check frequency: Every 1-5 minutes for critical endpoints.

When to Hire Your First Engineer

Founders ask me constantly: "When do I need to hire?"

Here are the signals I look for:

1. You're spending more time on infrastructure than features: Firefighting, optimization, maintenance eats your time.
2. Critical features are delayed by months: Your roadmap backs up because you can't build fast enough.
3. Technical debt is slowing you down: Simple changes take days instead of hours.
4. Users are churning due to bugs or missing features: You're losing customers faster than you can fix issues.
5. You have revenue to support a hire: Can you afford $80K-$150K/year without running out of money?

What to hire for (in priority order):

1. Full-stack engineer: Can build features end-to-end (most valuable early)
2. Backend specialist: If your scaling challenges are primarily server/database
3. Frontend specialist: If your UI/UX is limiting growth

Alternatives to full-time hire:

• Fractional CTO/engineer (part-time, less commitment)
• Technical co-founder (equity instead of salary)
• Contractor for specific projects (short-term help)

Most founders wait too long to hire. If you're asking "should I hire?" the answer is probably yes.

Five Scaling Mistakes That Break Products

Mistake 1: Premature Optimization

You optimize for 1 million users when you have 500. You build complex caching systems nobody needs. You rewrite working code because it "could be faster."

The fix: Optimize when you have data proving something is slow, not when you think it might be.

Mistake 2: Ignoring Monitoring Until It's Too Late

You don't set up error tracking. App crashes but you don't know until users complain. No idea which features are slow or broken.

The fix: Set up monitoring at 100 users. It's cheap insurance against disasters.

Mistake 3: Reactive Refactoring

Something breaks. You panic and rewrite everything. You "fix" working code because it's "messy." Deploy massive refactor that introduces new bugs.

The fix: Refactor strategically (when code prevents new features) not reactively (when you're stressed).

Mistake 4: Skipping Tests as You Grow

At 100 users, manual testing worked. At 1,000 users, you're breaking things with every deploy. Regressions pile up.

The fix: Add tests for critical workflows so you can deploy confidently.

Mistake 5: Hero Culture (Doing Everything Yourself)

You're the only one who knows how the system works. On-call 24/7. Every deploy requires you. Haven't documented anything.

The fix: Document critical processes. Share knowledge. Hire help before you burn out.

To Refactor or Rewrite? Making the Right Call

At some point, you'll look at your MVP code and think "this needs to be rewritten." Usually, you're wrong.

Refactor (improve existing code) when:

• Specific parts are hard to modify
• Adding features takes longer than it should
• You can isolate and improve small sections safely
• System mostly works but has technical debt

Rewrite (start from scratch) when:

• Core architecture fundamentally can't support your needs
• Technology stack is obsolete and unsupported
• Security issues are baked into foundation
• Cost of maintaining old code exceeds rewrite cost

Rewrites take 2-3x longer than you think and introduce bugs you forgot existed. Only rewrite when you have no other option.

If you must rewrite: Keep old system running, build new one alongside it, migrate features incrementally, run both in parallel until new one is proven.

---

About ShipSixty: I'm a fractional CTO working with Australian startups from pre-seed to Series A. I help non-technical founders build MVPs, hire technical teams, and make smart technology decisions. Based in Sydney, working with teams across Australia and remote. Learn more about how we work →

---

More in the Pre-Seed MVP Series

• Stop Looking for 'A Developer'—You Need a Technical Partner
• Validate Your Idea Before You Spend $50K Building It
• Don't Build Without a Blueprint—Here's How to Design Your MVP Right
• Ship Your MVP in 8 Weeks Without Cutting Corners
• You are here: Scale From 100 to 10,000 Users Without Everything Breaking