A live e-commerce store was failing its customers: stress tests showed roughly 0.7% of visits succeeded, the homepage took up to 41 seconds to respond, and server logs recorded 281,509 “Service Unavailable” errors on the worst day. We ran a fixed-price rescue: audit first, then a production-ready fix on the store’s existing hosting, no platform migration. By the end the store served 100% of test visits, loaded in under half a second, and its 503 errors were down 99.996% from the peak, measured across 2.75 million log lines.
The situation
A UK fashion e-commerce brand came to us with a shop that was actively losing sales. Customers were sending screenshots of error pages instead of placing orders. The owner did not need a lecture on architecture. She needed the shop to stop falling over, and she needed to know what it would cost before saying yes.
We audited the live site first. The numbers were stark.
| What we measured | May baseline |
|---|---|
| Visits that succeeded under load | About 0.7% (roughly 1 in 150) |
| Homepage response time | Up to ~41 seconds, when it responded at all |
| ”Service Unavailable” errors, worst day | 281,509 |
| Independent best-practices score | 73 / 100 |
The root cause was not the platform. It was load the server was never configured to survive: waves of automated bot traffic hitting an origin with no cache in front of it, compounded by plugin conflicts, an oversized image library, and a handful of outright bugs that had been shipped and never caught.
The approach: audit, fixed price, then fix
We scoped the work as a fixed-price engagement: 18 defined items, quoted in full before any work began. No hourly clock, no scope-creep bill. The owner knew the total on day one.
The work itself was ordinary production engineering, done in the right order:
- Put a network in front of the origin. A CDN plus layered bot filtering, so automated traffic is absorbed or blocked before it ever reaches the server. The bots that send real customers (search crawlers, AI citation bots) stay allowed.
- Serve pages from memory. A page cache so a real shopper gets a prebuilt page instead of one rebuilt from scratch on every request.
- Cut the waste. We removed a hidden background call making thousands of pointless requests a day, consolidated duplicate security plugins down to one, and collapsed two competing payment plugins into a single clean checkout path.
- Fix the actual bugs. A crashing product editor (an Elementor AI module), 800 broken links still pointing at a developer’s localhost address, placeholder text showing in the cart where a number belonged, and UK postcodes being rejected at checkout.
- Shrink the payload. Automatic image compression converted 96.8% of product images to a modern efficient format and saved 625 MB on disk, cutting roughly 40% of the image weight each page carries.
- Close the legal and trust gaps. UK-compliant refund, privacy, and terms pages, a working cookie consent banner, and enforced HTTPS.
We drove much of the audit and remediation through an AI-native toolchain, operating the site headlessly rather than clicking through admin screens, which is how a rescue like this fits inside a fixed price. If you want the technical detail, we wrote it up separately in driving WordPress headlessly with MCP.
Crucially: no platform migration. The store stayed on its existing hosting. A migration is sometimes right, but it is rarely the fastest way to stop customers hitting errors this week, and it was not needed here.
The results: from 503 errors to 100% availability
Measured through the end of the engagement, across 2.75 million server log lines over 29 days:
| What matters | Before | After |
|---|---|---|
| Can customers reach the shop? | ~0.7% of visits succeeded | 100% in testing |
| ”Service Unavailable” errors | Up to 281,509 in one day | About 10 per day (blocked attacks, not shoppers) |
| Homepage load time | Up to ~41 seconds | Under 0.5 seconds, roughly 90 times faster |
| Product images | All large JPG and PNG files | 96.8% converted to a modern format, 625 MB saved |
| Best-practices score | 73 / 100 | 96 / 100 |
The 503 count is a 99.996% reduction from the peak. The handful left each day are login attacks the hosting correctly refuses, not paying customers.
What made it work
Three things, and none of them are exotic.
We measured before and after. The 99.996% figure is not a claim, it is the difference between two log analyses over the same site. A rescue you cannot measure is a rescue you cannot trust.
It was a fixed price for a defined scope. The owner was not signing up for an open-ended engineering retainer against a broken site. She got a number, a list, and a finished result. That is the whole point: production-ready, at a price agreed up front, with no surprises.
She owns all of it. Every change is documented, on her own hosting, with no dependency on us to keep it running. We are proud of what changed. We are just as glad she does not need us to keep it working.
If your live product is falling over
The pattern here is common: something that worked in a demo, or worked at low traffic, starts failing when real users arrive. It is the same failure mode whether the product is a WooCommerce store, a vibe-coded prototype, or an MVP that outgrew its first build. This is the 70% problem in a different setting: the last stretch to production is where things actually break. The fix is the same shape too: measure honestly, harden what is there, and quote it as a fixed price so the person paying knows exactly what they are getting.