Design System & Guest Checkout at an E-Commerce Platform

Problem & constraints

I joined an e-commerce platform as its first dedicated frontend developer. Until then the frontend had been built by backend developers alongside their own work, without a reusable component layer to build from.

Two forces defined the work. First, the product needed a full design overhaul before its public release, with a UI designer whose Figma files were the contract; the designer had the last word on how things looked. Second, the product data was clear about where money was being lost: the product owner and a UX researcher found that many buyers reached a product page, clicked buy, got redirected to a login page, and never came back.

The team ran without a formal hierarchy: four backend developers working in Elixir, one developer covering both the database and DevOps, two Flutter developers on the mobile apps, and me on web. Each of us owned our domain and decided within it, aligned with the product owner; the big calls were made together with the CTO. What to build came from the CTO and the product and design side; my decisions were about how to build it on the web. My domain was the design overhaul, the component library, checkout, and authentication/authorization; later, mentoring two junior frontend developers as well.

The work came in stages. I did the overhaul alone in two weeks, from the homepage to every small menu page, and finished it for the public release. Smaller UI, UX and logic improvements followed as Jira issues from testers and the design side, and I started the component library alongside them, because the product still had none.

Architecture

Two client apps sit on the platform: the web app (Vue 3 with Quasar, Pinia for state, and the component library) and a Flutter mobile app for iOS and Android. The backend was mid-migration from a monolith to parallel Elixir microservices.

The new sign-in and purchase flow needed three pathways: registering an account, logging in to an existing one, and a guest checkout that asks only for what the purchase needs. The backend for registration was ready first, so the frontend work there was binding to it and getting the state management right. The backend for checkout was not ready, and it took another two to three months.

Checkout therefore ran client-side as a deliberate interim: the frontend built the cart, computed per-item and bundle discounts, called the payment provider directly, and received the result, because the backend could not yet serve live prices. Pinia stores carried the checkout state across steps, the auth sessions, and the admin-versus-user contexts, with role-based access checks in the router. Until the backend’s authorization was fully wired up, the frontend effectively was the access-control layer, so every step of every user story had to be walked for leaks and wrong-turn navigation. The decisions behind it are logged below, each with the alternative it beat.

Outcomes

The guest checkout measurably improved sales conversion: the abandonment point the UX research had identified was simply removed. The design system gave the team a shared component layer that cut the time to build features: around a hundred components, adopted by the entire team, matching the designer’s Figma while reusing Quasar underneath. Tests became trustworthy and mandatory per feature, and a GitHub Actions caching layer I added cut the app-packaging workflow, which ran on every merge, release, and test build, by roughly 40%.

The juniors I mentored moved from pair programming, through issue-driven guidance, to independently shipping better-shaped PRs with faster review cycles.

Lessons

I would have dropped Quasar at the first real inconvenience. The longer it stayed, the harder it became to let go, and bending its heavily-styled, class-laden components to match a designer’s bespoke system was a constant tax on exactly the work the design system was meant to make cheap. Wrapping a styled component framework under a pixel-contract design system means constantly fighting its opinions; if the designs are the contract, headless primitives (or your own) are the sounder foundation. It’s the clearest case of sunk-cost gravity I’ve worked through, and it changed how quickly I’m willing to re-litigate a foundation choice.