A web app in local development, with one browser tab and a warm dev server, tells you almost nothing about how it behaves under real traffic. Most of the issues that surface after launch aren't bugs in the code. The code works. They're assumptions that held at zero concurrent users and stop holding at fifty.
One of the most common is database connection exhaustion from serverless functions. Every invocation of a serverless API route can open its own database connection, and Postgres has a hard cap on how many it accepts, often around 100 by default. A traffic spike that triggers dozens of concurrent function invocations can exhaust that cap within seconds, and every request past the limit fails outright. The fix is a connection pooler sitting between the app and the database, not simply provisioning a bigger database instance.
A second common cause is caching that was assumed rather than actually configured. Modern frameworks ship real, powerful caching primitives (static rendering, timed revalidation, per-route caching rules), but they're opt-in decisions, not defaults that quietly protect an app on their own. A page that should be static but ends up rendering dynamically re-hits the database on every single request instead of once per revalidation window. That distinction is invisible with one user locally and becomes the entire story once thousands of people load the same page in an hour.
A third is client-side bundle size, specifically from interactive code placed higher in the component tree than it needs to be. Marking a whole page as client-rendered because one small widget on it needs interactivity drags every dependency that widget uses into the bundle sent to every visitor, even the ones who never touch that widget. It costs nothing on a fast connection during development and costs real, measurable load time on an ordinary mobile connection.
None of these show up in a demo. They show up in the first real week of usage, which is exactly why load-testing actual endpoints, checking connection pool behavior under concurrency, and auditing where interactivity boundaries sit are worth doing before launch, not after.
