I've watched a lot of small-business sites go from "nobody visits this" to suddenly busy — a viral post, a local news mention, a seasonal spike. The pattern of what breaks is almost never what junior devs assume it'll be.
Shared hosting caps out embarrassingly fast. A site that ran fine at 50 visitors a day can fall over at 500 if it's on a $5/month shared plan, regardless of how clean the code is. The fix usually isn't a rewrite — it's a hosting tier upgrade and basic caching. I've seen developers spend a week optimizing queries on a site whose real bottleneck was a shared CPU allocation.
Forms fail silently before pages do. Under load, the contact form or checkout is often the first thing to quietly stop working — a timeout, a plugin conflict, an email service rate limit — while the rest of the site looks completely fine. Nobody notices because nobody's staring at form submission logs on a small business site. This is the single most common "why did we lose two weeks of leads" conversation I have with clients.
Nobody has a plan, because nobody expected to need one. Enterprise projects get load-tested. A local bakery's site does not. When traffic spikes, the client's instinct is to email you in a panic rather than check a dashboard, because there was never a dashboard to check. Even a bare-minimum uptime and form-delivery monitor, set up at launch, turns a fire drill into a five-minute fix.
The client's real question is never "is it down," it's "am I losing money right now." Technical postmortems don't land with this audience. What lands is: here's what broke, here's what it likely cost you, here's what changes so it doesn't happen again. Framing incident reports around business impact instead of root cause is what actually keeps the retainer.
If you build for small businesses instead of scaled products, "handling traffic" isn't a system design problem — it's a monitoring and expectations problem. The code is rarely what fails first.
Top comments (0)