When We Tell Clients to Stop Optimizing and Just Rebuild

Last year, after several months of performance work on a client’s Shopify store, our lead developer wrote something in an email that stuck with me: “My recommendation is that we build a new theme. I know that’s not what you were hoping to hear, but the results will be meaningfully better and the new theme will be significantly easier to maintain going forward.”

That’s a hard thing to say to a client. It can sound like you’re walking away from work you’ve already done, or like you’re upselling them on something bigger. In this case, it was neither. It was the honest answer after spending enough time in the codebase to know the ceiling.

The theme in question was several years old. It had been customized significantly over time: new sections added, third-party scripts layered on, structural changes made by multiple developers who each left their own mark. The performance issues weren’t isolated. They were woven through the theme itself, and fixing one would usually surface another. We had made real improvements. But the improvements were getting harder to make and the ceiling was getting closer.

We recommended a rebuild. The client agreed. The new theme launched faster, performs significantly better, and costs less to change because we understand every line of it.

That’s the case for rebuilding. But it’s not always the right call.

The optimization trap

The seductive thing about optimization is that it always produces something. Compress that image, defer that script, remove that unused CSS. Each change makes a measurable difference. So you keep going. And the improvements keep getting smaller. And the hours required keep getting larger.

The optimization trap is when the cost of incremental improvement exceeds the value it delivers, but the client (or the agency) keeps going because stopping feels like giving up.

Technical debt works the same way. Each patch on an aging theme is a small decision that makes sense in isolation. But patches don’t clean up the underlying structure. They add to it. A theme that’s been patched by five different developers over four years isn’t one theme. It’s five themes stacked on top of each other, each one making the next problem harder to diagnose and the next fix riskier to implement.

The specific performance ceiling this creates looks like this: you get LCP from 6 seconds down to 4 seconds with a round of optimization work. Then you spend the same effort getting it from 4 seconds to 3.5 seconds. Then you’d need twice the effort to get it to 3 seconds, and the underlying structure of the theme makes sub-3 genuinely impossible without rearchitecting the way it loads. You’re fighting the foundation.

Four questions that drive the decision

When a client comes to us with a performance problem, these four questions shape whether we recommend optimization or a rebuild.

1. How old is the theme and how heavily customized is it?

A theme that’s two years old with light customization is almost always a candidate for optimization. A theme that’s five-plus years old that’s been modified by multiple developers is usually a rebuild candidate. The age matters less than the accumulated complexity, but age is a reasonable proxy.

2. What’s the performance ceiling?

We audit the theme to understand what “done” looks like. If Core Web Vitals can reach acceptable levels (LCP under 2.5s, CLS under 0.1) with targeted optimization work, optimization makes sense. If the theme’s architecture makes that genuinely impossible (because of how it loads resources, how app scripts are integrated, or how the DOM is structured), we say so.

3. What’s the growth horizon?

If the client is planning a major expansion, new market launch, or significant product catalog growth in the next 12 months, a rebuild that positions them correctly for that growth is usually better economics than optimizing a theme they’re going to outgrow anyway. If the business is stable and the changes are incremental, optimization preserves institutional knowledge without disruption.

4. How much do ongoing changes cost?

This is the question most clients don’t think to ask. A heavily customized theme isn’t just a performance problem. It’s a maintenance burden. Every change takes longer because the developer has to understand someone else’s patch before touching it. The hourly cost of changes on a clean, well-structured theme is meaningfully lower than on one that’s been modified by multiple hands over several years. Rebuilds often pay for themselves in reduced maintenance costs, and the more hands that have touched the old theme, the faster that tends to happen.

When optimization wins

Optimization is the right call when:

• The theme is relatively recent (under 3 years old) with straightforward customizations
• The performance problems are specific and isolatable: a particular script, a specific section, a single template
• The timeline doesn’t allow for a rebuild (upcoming sale season, pending migration, etc.)
• The client’s development budget doesn’t currently support a full rebuild

In these situations, a focused optimization engagement (auditing the theme, identifying the specific drag, making targeted changes) delivers real value without disruption. We do a lot of this work and it’s often exactly the right answer.

When a rebuild wins

A rebuild makes more sense when:

• The theme is outdated and the performance ceiling is structural, not addressable with optimization
• Developer time spent on changes keeps exceeding estimates because of accumulated complexity
• The business has meaningful growth plans that the current theme isn’t positioned to support
• App and integration debt has built up to the point where the script load is fundamentally a theme architecture problem
• The client is planning a significant redesign anyway, in which case rebuilding clean is more efficient than redesigning on top of an old foundation

The rebuild doesn’t have to be disruptive. We use a parallel development approach: the new theme is built in a separate theme slot in Shopify while the existing store runs without interruption. The client can preview, review, and test the new theme against real content before any customer-facing change happens. Launch is a single click to publish the new theme. No downtime, no customer impact.

The honest version

The honest version of this conversation is that we don’t always know which side of the line a client is on until we look at their codebase. The four questions above are a starting framework, but the actual answer comes from spending time in the theme and understanding what the specific problems are.

If you’re dealing with persistent performance problems on a Shopify store and you’re not sure whether you’re in optimization territory or rebuild territory, a site audit is the clearest starting point. We audit the theme health, benchmark the performance ceiling, and tell you specifically what we’d do and why, without a predetermined answer.

Sometimes it’s optimization. Sometimes it’s a rebuild. Sometimes it’s neither and the real problem is somewhere else entirely. The goal is to tell you the truth and let you make the decision with full information. For an example of what a successful rebuild looks like in practice, see our Amarra case study.

Last Updated: April 2026