The Platform Problem
When I joined Purple Carrot in 2021, the platform was a custom-built system originally architected in 2017 for four meal kit SKUs. By the time I arrived, we were running 98 SKUs across multiple product lines, all forced into a data model that was never designed for that complexity.
Pricing was hard-coded to plan size. There was no flexible metadata layer for products. The subscription sign-up flow was a 10-step linear funnel that required full account creation before a customer could even browse the current menu. Despite the fact that we didn't charge at checkout (authorization ran on a weekly batch cycle), the experience felt transactional from the first click.
Roughly 40% of new sign-ups each month never placed a first order. They converted on paper, abandoned in practice.
This wasn't a design problem or an engineering problem. It was an architecture problem, and it was constraining every team in the building.
The Hypothesis
The opportunity was clear and had been circulating for years: build an e-commerce-style shopping experience that lets prospects browse the full weekly menu before committing to an account. Reduce friction at the top, increase intent by the time a customer hits checkout.
I'd been building evidence for this direction through user testing, competitive analysis (HungryRoot, HelloFresh, and Blue Apron had all moved toward variations of a shop-first model), and internal data showing where prospects dropped. The target was a 5-point lift in conversion rate and a meaningful reduction in zero-order sign-ups.
When leadership greenlit it for the roadmap, it meant we could finally break out of the legacy architecture, retire the old design system, and rebuild the core customer journey from the ground up.
What I Inherited vs. What It Required
This was scoped as a product initiative. In practice, it was a platform re-architecture, a full UX redesign, and a cross-functional change management effort, all at once.
I had a capable APM and a strong visual designer. But the scope demanded senior-level design systems thinking, deep legacy platform knowledge, and cross-functional program leadership that, at the time, only existed with me. As the most tenured member of the technology team, I was the only person with full context on the system's constraints, the interdependencies across teams, and where the landmines were buried. So I stepped into three roles at once: design lead, product lead, and program director.
How I Structured the Work
The first thing I did was build the scaffolding. Not for the product, but for the team.
Weekly Execution Slices
Week-over-week increments: design delivers screens, product finalizes requirements and secures sign-off, cards are groomed for engineering by Friday. No week had slack, so communication had to be airtight.
Daily Standups with Leads
Morning and end-of-day check-ins with the APM, designer, and engineering leads. Morning syncs surfaced blockers. Evening syncs tracked whether we were holding the line.
Decision Log
A single source of truth: what was decided, when, by whom, and what data supported it. Stakeholders had a pattern of revisiting decisions. The log saved weeks of rework.
Stakeholder Comms as a Workstream
I took full ownership of upward and lateral communication (CEO updates, cross-functional alignment, expectation management) so my team could stay focused on building.
Key Decisions
Choosing Mantine as the component library. I evaluated design pattern libraries compatible with our React stack, prioritizing speed of designer adoption, built-in responsive behavior, and component density that matched our information-heavy UI. Mantine gave our designer a system she could compose with quickly and gave engineering a consistent, well-documented foundation. This decision accelerated design velocity for the remainder of the project and beyond.
Mobile-first breakpoint strategy. I pulled device data from Google Analytics to identify the breakpoints that mattered most for our actual user base, rather than defaulting to generic responsive tiers. This gave design and engineering a shared, data-backed frame of reference for every screen.
Pushing back on the timeline. Leadership set a target launch date tied to the pre-holiday acquisition season. When I assessed our velocity against scope, I flagged early that the date was not achievable without cutting quality or burning out a small team. I was direct: we renegotiated scope and sequencing instead.
What Shipped
The redesign fundamentally changed how customers discovered, evaluated, and committed to Purple Carrot.
A new conversion model. Prospects could now browse the full weekly menu, build a box across product lines, and reach checkout with real purchase intent, not just an email capture. The legacy 10-step sign-up funnel was replaced with an e-commerce-style shopping flow.
A flexible product metadata layer. Products could now carry attributes like dietary tags (gluten-free, high-protein, under 600 calories), enabling marketing to run thematic campaigns, culinary to organize the menu with more nuance, and critically, laying the data foundation for a personalized matching algorithm on the 2026 roadmap.
Cart architecture supporting multiple user states. New APIs mapped between logged-out prospects and logged-in subscribers, allowing cart persistence and recovery across sessions. An infrastructure investment that unlocked features well beyond the initial redesign scope.
A scalable design system. The Mantine adoption gave the product team a repeatable, consistent design language for the first time, reducing the per-feature design cost for everything that followed.
What It Unlocked
Higher average order value through cross-product-line cart building. Customers could mix meal kits, prepared meals, and add-ons in a single flow
Reduced zero-order sign-ups by ensuring prospects had already built a box they wanted before creating an account
Marketing deep linking into specific products from email and SMS, previously impossible with the old architecture
Operational efficiency for the culinary team through structured metadata and standardized product data
A standard selling model across the platform that every team could build on, rather than working around
What I'd Do Differently
I carried more ambiguity than I needed to. My instinct was to protect the team from the chaos above them (the shifting opinions, the pressure, the scope of what we were unraveling) and absorb it myself. That worked in the short term, but it limited my team's growth. Given the chance again, I'd create more structured exposure to that ambiguity earlier, with guardrails, so they could build the muscle while I still held the safety net.
I'd also negotiate headcount harder before committing to the timeline. The scope was a full platform re-architecture with a skeleton crew. I made it work, but the cost was personal, and the organization benefited from effort it didn't fully resource.
This project represents the intersection of where I operate best: diagnosing a systems-level problem, building the structure for a team to execute against it, and making hard calls when the organization's ambition outpaces its capacity.