Scale & Performance
Scaling work addresses the difference between an app that behaves correctly for one person clicking slowly and an app that behaves correctly for hundreds of people at once.
Prototypes are tested by their author, one action at a time, against a database holding maybe fifty rows. Nothing about that resembles production, so nothing about it surfaces the problems production has.
The failures are consistent and mostly unglamorous. A query with no index that was instant at fifty rows takes eight seconds at fifty thousand. A list view that issues one database call per item. An AI feature with no spend cap. A file upload with no size limit. None of these are exotic. All of them are invisible until they are urgent.
This sounds like you if…
- “It was fast last month and now it isn't.”
- “It falls over whenever more than a few people use it at once.”
- “My hosting bill went up ten times and I don't know why.”
- “My OpenAI or Anthropic bill is unpredictable and rising.”
- “Pages load slowly and users are dropping off.”
What this covers
- Measure before changing anything. Performance work driven by intuition usually optimizes something that was not the problem.
- Fix the database layer: add the missing indexes, eliminate queries issued in loops, and stop fetching entire tables to display ten rows.
- Add caching where the data genuinely tolerates being slightly stale, and not where it does not.
- Put hard limits and monitoring on anything metered — AI APIs especially, where a loop can generate a large bill overnight.
- Move slow work into background jobs so a user request is not waiting on it.
- Set up monitoring and alerting, so the next problem is something you detect rather than something a customer reports.
Worth knowing
Scale & Performance — questions
How many users can my app handle right now?
Unknown until it is measured, and anyone who answers that from a description is guessing. Load testing against a realistic data volume gives you a real number, and it is usually a fast piece of work.
Do I need to rewrite to scale?
Rarely. Most early scaling problems are database and configuration issues rather than architectural ones. Genuine architectural limits exist, but they are further out than most people fear and should be demonstrated with measurements before anyone proposes a rewrite.
How do I stop my AI API costs running away?
Hard spend caps at the provider, rate limiting per user, caching identical requests, and alerting on unusual volume. This is a day of work and it is the single best-value protective measure available if your app calls a paid model.
Not sure how bad it is? That's the normal starting point.
Tell us what you built and what's worrying you. If the honest answer is that you don't need us, we'll say so.