This began as a focused frontend tidy-up and became a six-week storefront rebuild. I designed and implemented a modular WooCommerce theme, a separate editor plugin and five core customer-facing templates for the agency managing the live site.
The engagement ran from mid-March to the end of April 2026. Once I audited the predecessor, it was clear that polishing the surface would leave the same structural problems underneath. The better answer was to separate presentation, reusable editor data and commerce behaviour properly.
I owned the design and frontend implementation. The managing agency kept responsibility for hosting, final integration and the live cutover.
The job to be done
The storefront needed a calmer editorial direction, a more maintainable frontend and a safer way for editors to control recurring content without making every change a development release.
- Homepage — establish the new visual language and reusable content sections.
- Shop archive — keep product discovery practical while simplifying the surrounding interface.
- Product page — preserve the WooCommerce buying journey inside the new theme structure.
- FAQ — give support content a clear hierarchy and usable interaction pattern.
- Brands page — present catalogue relationships in a more coherent editorial layout.
The architecture behind the redesign
I built the replacement theme with Timber and Twig templates, WooCommerce as the commerce model, feature-level CSS and a small vanilla-JavaScript runtime.
The main architectural change was ownership. Shared layout, page-specific features and WooCommerce integrations were separated so changing one route did not mean loading or editing one large frontend bundle.
Assets loaded by route
Page and component styles were loaded where they were needed. Product galleries, navigation, filters and other interactions were focused modules instead of a sitewide chain of unrelated dependencies.
WooCommerce stayed in charge of commerce
The new templates continued to use WooCommerce as the source of truth for products and transactions. The theme changed presentation around those objects and actions rather than rebuilding catalogue logic inside the visual layer.
Editor data survived the theme
I put recurring editor-owned content in a companion plugin. That meant data the team needed to manage was not trapped inside a theme that might eventually be replaced.
Visual direction
The predecessor felt dense and highly saturated. I moved the storefront toward a calmer editorial system with clearer typography, more deliberate spacing, stronger product-card hierarchy and better use of photography.
The five templates still had different jobs—discovery, persuasion, support and brand presentation—but they now felt like parts of the same storefront instead of separate page designs.
How I delivered the sprint
- Audit the predecessor. Identify shared frontend weight, template dependencies and the editor pain points causing routine friction.
- Set the visual system. Establish typography, colour, spacing and repeatable content patterns.
- Build through real templates. Implement the five core routes against WooCommerce and actual content needs.
- Separate editor data. Keep reusable content controls in the plugin rather than the theme.
- Hand over cleanly. Supply the theme and plugin for integration and live release inside the agency’s managed environment.
Performance and proof
The performance work focused on causes I could control: reducing shared frontend weight, loading feature CSS by route, using vanilla JavaScript and handling WooCommerce assets deliberately.
I do not publish a before-and-after Lighthouse or LCP claim here because the raw comparison files from the predecessor and staging environments were not retained with this project. The page therefore shows the architecture and delivery scope I can support, rather than a number I cannot reproduce.
What this project demonstrates
One person carried the interface from audit and visual direction through five real ecommerce templates, modular frontend implementation and a hand-off package for the agency responsible for launch.
Six weeks is not a universal benchmark. The useful point is that the scope stayed focused, the ownership boundaries were explicit and the final theme was designed to be operated by the next team rather than only by its original developer.
Planning a storefront rebuild?
Start with the routes that drive product discovery, evaluation and checkout. Then make content ownership, integration and rollback explicit before the visual scope expands.