When a site is broken, the instinct is to burn it down and start clean. New stack, fresh architecture, no baggage. It feels decisive. It feels like progress.
Most of the time, it’s the wrong call.
How officeworks.ph Landed on My Desk
They came to us knowing something was wrong. The site was built on WooCommerce — reasonable choice for e-commerce, widely supported, low barrier to get started. It worked fine until it didn’t. Real traffic hit, hundreds of concurrent users, and the site buckled. Slow page loads, poor performance under load, a shopping experience that was quietly killing conversions.
They’d already diagnosed themselves: we need a rebuild.
That’s the part I want to stop at. Because “we need a rebuild” is a conclusion, not a diagnosis. And accepting that conclusion too quickly is how projects blow their remaining budget on work that didn’t need to be done.
The Actual Diagnosis
We looked at what they had. WooCommerce handling the backend — inventory, orders, product data, the commerce logic. All of that was functional. The problem wasn’t WooCommerce itself. The problem was that WooCommerce’s default frontend was doing too much work on every page load, and it wasn’t built to handle the traffic they were seeing.
The backend wasn’t the patient. The frontend was.
So instead of scrapping everything, we made a specific decision: keep WooCommerce as the backend engine, replace only the front end. We rebuilt it in NuxtJS — a Vue-based framework that pre-renders pages, loads fast, and doesn’t choke under concurrent users.
The result was a site that performed. Load times dropped significantly. The shopping experience became what it should have been from the start. The business is profitable now in a way it wasn’t before.
And we did it on a limited budget, because we didn’t rebuild what didn’t need rebuilding.
What This Actually Taught Me
The most expensive mistake in mid-project rescues isn’t the technology. It’s the framing.
When a client comes in saying “we need to rebuild,” they’re usually right that something is broken. They’re often wrong about how much needs to change. The job isn’t to agree with their proposed solution — it’s to find the smallest accurate diagnosis and work from there.
In this case: the data layer was fine, the rendering layer wasn’t. Fix the rendering layer.
This applies beyond WooCommerce. I’ve seen it with custom CMS builds, with Laravel backends that had perfectly good APIs attached to front ends that were the actual problem, with Shopify stores where the theme was the bottleneck and not the platform. The pattern is the same. Something breaks, the whole thing gets blamed, and the proposed fix is bigger than the actual problem.
When a Full Rebuild Is Actually Right
I’m not arguing against rebuilds. Sometimes the architecture is genuinely wrong from the ground up — wrong data model, wrong platform for the use case, technical debt so deep that working around it costs more than replacing it.
But that’s a different situation from what officeworks.ph had. They had a solid backend, a clear performance problem, and a constrained budget. The answer was surgical, not wholesale.
The question I ask before recommending any significant rework: what specifically is broken, and what is still working? If you can draw that line clearly, you usually don’t need to blow up the whole thing.
The tricky part is that clients often come in with a solution already in hand, and it takes some confidence to push back on it — especially when they’ve already decided. “We need a rebuild” is a hard thing to argue against without a clear alternative ready.
That alternative has to come from actual diagnosis, not instinct. I’m still working out how to make that diagnostic conversation faster and less friction-heavy in early client engagements. It’s something I’m folding into how ArwenHQ handles project onboarding — but that’s a separate post.