Scale Readiness
Make launch day boring
Big launch, funding round, Product Hunt, seasonal spike? I find the cliff before your users do — then fix it. Capacity planning, load testing, autoscaling, and architecture that holds.
Sound familiar?
Built for 1,000 users, now you need 100,000
Traffic spikes cause outages
The marketing push works — and the site falls over at the worst possible moment. The spike you wanted becomes the incident you remember.
The database is the bottleneck
Connection pool exhausted, slow queries pile up, replicas lag. Adding app servers does nothing because the DB is the wall.
Autoscaling that doesn't
Scaling rules tuned once and forgotten. It scales too late, too slow, or thrashes — and the cold-start stampede makes things worse.
No idea where the cliff is
You have never load-tested. Nobody knows if you break at 2× or 20× current traffic — so every growth event is a gamble.
How I work
Find the cliff, then move it
1. Scan — free 30-min call
Walk me through your stack and the upcoming event. I name the three most likely failure points and what we need to confirm them. No commitment.
2. Load test & capacity plan
Realistic load tests on staging (k6/Gatling/JMeter) modelling your expected traffic shape. Find the breaking point, the bottleneck behind it, and the headroom you actually have.
3. Harden — with your team
Fix the bottlenecks: query/index tuning, caching, connection pooling, autoscaling rules, queue-based load levelling, graceful degradation. Re-test to prove the new ceiling. Plus a runbook for the day itself.
What you get
A system that holds — and proof that it does
Reusable scenarios that mirror real traffic. Run them before every big event, not just once.
Headroom per component, scaling triggers, cost-at-scale projection. Know your ceiling in numbers.
Right triggers, right cooldowns, warm pools. Scales before users notice, not after they leave.
Pooling, read replicas, query/index fixes, caching layer. Remove the most common scale wall.
Queue-based load levelling, backpressure, circuit breakers, graceful degradation under overload.
What to watch, what to do when it goes red, who to call. Calm instead of chaos.
Engagement options
Three ways to work together
Fixed scope
Readiness sprint
2-3 weeks
- ✓ Load test + capacity plan
- ✓ Prioritised bottleneck list
- ✓ Autoscaling review
- ✓ Launch-day runbook
Hands-on
Sprint + fixes
From 4 weeks
long-term if needed
- ✓ Everything in Readiness sprint
- ✓ Ship the hardening with your team
- ✓ Re-test to prove new ceiling
- ✓ On-call support for the event
Common questions
How much lead time do you need before a launch?
Ideally 3-4 weeks so fixes can be tested and rolled out calmly. I take last-minute work too, but with less lead time the focus shifts to risk triage and a solid runbook rather than deep fixes.
Will load testing affect production?
Tests run against a staging environment that mirrors production, or against production during a controlled window with your sign-off. Never a surprise hit on live users.
What if the fix is "buy a bigger server"?
Sometimes that is genuinely the cheapest answer for a one-off event, and I will say so. More often the real win is a query fix, a cache, or an autoscaling tweak that costs nothing extra to run.
Do you cover the database specifically?
Yes — the database is the most common scale wall. Connection pooling, read replicas, query/index tuning, and caching are core to the work. PostgreSQL, MySQL, and the usual suspects.
Can you be on call for the actual launch?
Yes, on the hands-on engagement. I watch the dashboards with your team during the event and help respond if something goes red.
Don't let your big moment become an incident
30 minutes, your launch plan, the three things most likely to break — and how to stop them.