Run basic load tests against my staging environment before launch. I want to know where the app breaks and roughly how much traffic it can handle, not with production users but with a real test. Set up the test: 1. Pick a tool: k6, Artillery, Locust, or hey/wrk for simple cases. Ask which fits before installing; something with a scriptable scenario is worth it because a login-then-do-a-thing test is way more useful than a single-URL hammer. 2. Write two or three scenarios that reflect real usage: an unauthenticated homepage/read-heavy scenario, a sign-in-then-do-the-main-action scenario, and (if payments matter) a checkout scenario against Stripe test mode. Weight them roughly like real traffic. 3. Run against staging (not production), starting low and ramping. Look for the point where p95 latency spikes or error rate rises. Note the request rate at that point. That's your soft ceiling. 4. While the test runs, watch database CPU/connections, app instance CPU/memory, and any queue depth. Whichever hits 80%+ first is your actual bottleneck (probably the database or a single-threaded worker). 5. Address the top one or two bottlenecks (missing index, connection pool too small, N+1 query under load, single instance instead of multiple). Rerun the test to confirm the ceiling moved. 6. Document the results: 'staging can sustain X requests per second at Y latency; expected launch traffic is Z; safety margin is W'. Include what you'd scale first if traffic exceeded expectations. Don't load-test production; you'll cause the outage you're trying to prevent. Don't chase a fake number by testing a single endpoint that doesn't reflect real load. The deliverable is scripts checked into the repo, a run report against staging, the top bottlenecks fixed, and a documented capacity number I can point to.