Scaling advice on the internet is written by people operating at a scale you do not have. A thousand users is a small number for any modern machine — one cheap server handles it comfortably, provided you avoid a specific handful of mistakes.

What actually breaks

N+1 queries. Fetch a list, then run one query per item. Fine with ten rows, fatal with ten thousand. This is the most common cause of a small app falling over, and it's usually one loop.

Missing indexes. A query without one scans every row. Invisible at 100 rows, painful at 100,000. Index the columns you filter and sort by.

Unbounded queries. SELECT * with no limit on a table that grows. Fine on launch day, not in March.

Work done during the request that belongs in the background: sending email, calling slow APIs, processing images.

No cap on anything that costs money. A loop, or a bored stranger, runs your API bill up overnight.

What doesn't break

Your language being slow. Your framework's overhead. Not having a cache. Not running containers. Being on one server. These are the things people optimise, and at this size they are almost never the constraint.

scale-check.txt
My app: <stack, what it does>. Currently <n> users, expecting <n>.

Don't give me general scaling advice. Look at this code and tell me
specifically:
- Where are the N+1 queries?
- Which queries have no index behind them, and no limit?
- What runs during a request that should run after it?
- What is unbounded — anything that grows without a cap?

Rank by what breaks first as I grow, and estimate at roughly what size.

Add monitoring before you need it

You want to know something broke before a user emails you about it. An uptime check pinging your site every few minutes, and error reporting that captures exceptions with a stack trace. Both have free tiers. Half an hour of setup, total.

The number that matters isn't requests per second. It's whether you'd find out that signups had been failing for two days.