Constructor Migration
Replacing ~⅓ of the Ruggable customer experience in 3 months, ahead of peak season.
Summary
- Scope: Replaced the entire search and merchandising infrastructure across global Shopify storefronts — touching nearly every page on site.
- Constraint: Hard deadline of end of October 2025 to land before Black Friday / Cyber Monday traffic peak.
- My role: Inherited the project mid-flight (vendor already selected). Owned scoping, planning, cross-functional alignment, QA, and launch.
- Outcome: Shipped on time with zero P0 incidents, contributing to a 15% YoY increase in Search CVR and unlocking new merchandising capabilities.
Context
When I picked this up, the vendor (Constructor) had been selected but no detailed plan existed. The project was framed as a like-for-like swap of search and merchandising - but in reality it touched ~⅓ of the customer experience: PLPs, search results, navigation, recommendations, and the merchandising tooling our category teams used daily.
The deadline wasn't negotiable. Anything not live before code freeze in late October would slip past holiday season, and BFCM is when Ruggable does a meaningful share of its annual revenue. Shipping late wasn't an option. Shipping broken was worse.
Approach
1. Scoped the gap before scoping the work
Rather than treat this as a swap, I wrote a full PRD that mapped current functionality against Constructor's out-of-the-box capabilities. This surfaced the gaps early - features we'd lose, features we'd need to rebuild, and features we could deprecate.
That document became the single source of truth for engineering, merchandising, and leadership for the duration of the project.
2. Took an engineering-led posture on a tech-heavy initiative
This wasn't a UX-led project; it was infrastructure. I worked closely with the engineering lead and explicitly let them drive sequencing decisions where their judgment was sharper than mine. My job was to keep scope honest, unblock decisions quickly, and protect the timeline.
3. Ran merchandising migration in parallel
The platform change was only half the work. The merchandising team had years of workflows, data models, and curated collections built into the old system. I ran a parallel workstream to:
- Audit existing collection pages and search rules - removing hundreds of redundant rules and outdated collections as part of the cleanup
- Map old workflows to new Constructor equivalents
- Train the team on the new tooling before launch, not after
This meant they walked into BFCM with confidence in the new system, not learning it under pressure.
4. QA bit by bit, not all at once
With a third of the site changing, a single end-to-end QA pass would have been a disaster. I broke the surface area into discrete chunks: search results, PLPs, navigation, recommendations, faceting, redirects, SEO, and we tested and signed off on each independently. A running QA log gave leadership visibility on progress and risk in real time.
Outcome
- Launched ahead of code freeze in October 2025, before BFCM.
- Zero P0 incidents at launch.
- Contributed to a 15% YoY increase in Search CVR (FY2025).
- Unlocked new merchandising capabilities the previous stack couldn't support, including dynamic collections and AI-powered recommendations.
- Merchandising team self-sufficient on the new platform from day one.