Scaling Expectations
Your app works. Users are signing up. Things are going well.
Then one day, the app starts getting slow. Pages take forever to load. The database crashes. Users start emailing you about errors.
You've hit a scaling problem.
This page explains why AI-generated code often fails under load, what to expect as your app grows, and how to prepare for growth without over-engineering.
The Scaling Reality
Most AI-generated code is optimized for one thing: working correctly in a demo.
It is not optimized for:
- Handling 100 users at the same time
- Processing large amounts of data
- Running efficiently on production hardware
- Maintaining performance under load
This is fine for prototypes and MVPs. But if your app succeeds, you'll need to address these issues.
What Breaks First
1. The Database
This is the most common scaling bottleneck.
| Problem | What Happens | Why AI Code Does This |
|---|---|---|
| N+1 queries | Loading 100 users triggers 101 database queries instead of 1 | AI generates simple loops without optimizing database access |
| Missing indexes | Searching a table with 10,000 rows takes seconds | AI doesn't add indexes unless explicitly told |
| No pagination | Loading "all records" works with 10 records, crashes with 10,000 | AI loads everything into memory |
| Wrong database | SQLite handles 1 user fine, crashes with 10 concurrent users | AI chooses the simplest option |
What to do:
- Add database indexes on fields you search or filter by
- Implement pagination for any list view
- Use a production database (PostgreSQL) instead of SQLite
- Monitor slow queries and optimize them
2. File Storage
| Problem | What Happens |
|---|---|
| Local storage | Uploaded files fill up your server's disk space |
| No CDN | Images load slowly for users far from your server |
| No compression | Large files take forever to download |
What to do:
- Use cloud storage (AWS S3, Cloudinary, Uploadthing) instead of local storage
- Enable CDN for serving static files and images
- Compress images automatically on upload
3. API Performance
| Problem | What Happens |
|---|---|
| No caching | Every request hits the database, even for data that rarely changes |
| Synchronous operations | Slow operations block other requests |
| No connection pooling | Each request opens a new database connection |
What to do:
- Add caching for frequently accessed, rarely changed data
- Use connection pooling for database connections
- Move slow operations (email sending, file processing) to background jobs
4. Frontend Performance
| Problem | What Happens |
|---|---|
| No lazy loading | The entire app loads at once, even pages the user hasn't visited |
| Large images | Unoptimized images slow down page load |
| Too many requests | Each page makes 50 separate API calls |
| No code splitting | The JavaScript bundle is huge |
What to do:
- Lazy load images and components
- Optimize and compress images
- Batch API requests where possible
- Enable code splitting
Scaling Stages
Stage 1: Prototype (1-10 users)
What works: Everything. Your app runs fine on a cheap server or free tier.
What to focus on: Getting the product right, not optimizing for scale.
Database: SQLite or free-tier PostgreSQL is fine.
Stage 2: Early Users (10-100 users)
What works: Most things, but you might notice occasional slowdowns.
What to focus on: Add monitoring, fix obvious performance issues.
Database: Switch to PostgreSQL if you haven't already. Add basic indexes.
What might break: N+1 queries, missing pagination.
Stage 3: Growing (100-1,000 users)
What works: Core features, but you'll start seeing performance issues regularly.
What to focus on: Caching, background jobs, database optimization.
Database: Add more indexes, optimize slow queries, consider read replicas.
What might break: File storage limits, API response times, database connection limits.
Stage 4: Scaling (1,000-10,000+ users)
What works: Core features with caching and optimization.
What to focus on: Horizontal scaling, CDN, microservices (if needed).
Database: Connection pooling, read replicas, query optimization.
What might break: Everything needs to be designed for scale at this point.
What NOT to Do
Don't Prematurely Optimize
The biggest mistake new developers make is optimizing for scale before they have users.
Don't:
- Set up a complex microservices architecture for a prototype
- Spend weeks optimizing database queries that run 10 times a day
- Buy expensive enterprise hosting before you have revenue
Do:
- Build it simply first
- Add monitoring so you know when something becomes a problem
- Fix issues when they actually appear, not before
Don't Ignore Problems
The second biggest mistake is ignoring performance issues when they appear.
Don't:
- Hope users won't notice slow load times
- Assume "it'll be fine" when you see database errors
- Put off adding indexes because "it works for now"
Do:
- Fix performance issues as soon as you notice them
- Monitor your app so you notice issues before users do
- Plan for growth, even if you're not there yet
Cost-Effective Scaling
You don't need expensive enterprise solutions. Here's how to scale on a budget:
| Need | Budget Solution | Enterprise Solution |
|---|---|---|
| Database | PostgreSQL on a $10/month VPS | Amazon RDS, Aurora |
| File storage | Cloudinary free tier, S3 | CloudFront CDN, S3 + CF |
| Caching | In-memory caching (Node.js/Python) | Redis, Memcached |
| Background jobs | Simple queue in database | RabbitMQ, SQS |
| CDN | Cloudflare (free tier) | Cloudflare Enterprise, Akamai |
| Monitoring | Sentry free tier + Uptime Robot | Datadog, New Relic |
The Scaling Checklist
- Database has indexes on frequently queried fields
- List views have pagination
- File uploads use cloud storage (not local)
- Images are optimized/compressed
- Static assets are served via CDN
- Frequently accessed data is cached
- Slow operations use background jobs
- Database connection pooling is configured
- API responses are paginated
- Frontend uses lazy loading
- JavaScript bundle is code-split
- Monitoring is in place to detect performance issues
- Load testing has been done (even basic)
- A plan exists for the next growth stage
The Bottom Line
AI-generated code works great for prototypes. Scaling requires engineering.
The good news: most scaling problems are well-understood and have standard solutions. You don't need to be a senior engineer to fix them — you just need to know what to look for and when to address it.
Build for today. Monitor for tomorrow. Scale when you need to.