A custom eCommerce ERP for a 16,000-SKU foodservice & packaging operation.

The business sells across seven distinct product categories — disposables, smallwares, food & beverage, tabletop, equipment, storage & transport, janitorial, industrial — plus a customizable-products line where customers order custom-printed cups, bags, boxes, and labels with their own artwork. Each category has different attributes, different supplier networks, different fulfilment paths, and different margins.

When I joined, the back-office was a stack: a separate PIM for catalog, spreadsheets for forecasting, a custom queue for the custom-print orders, a different tool for B2B quotes and catering bulk orders, another for the rewards programme, and email threads for supplier POs. The business was scaling. The tooling wasn't.

"The catalog grew faster than the team could keep up with. We had product managers chasing sustainability claims across three systems and warehouse leads guessing at restock priorities. The ERP exists to fix that." — Founder brief, first week on the job

Three specific problems to solve:

• No design system. Eight modules were being designed by different people in different Figma files, with 40+ inconsistent patterns shipping every sprint. Buttons, tables, and forms were implemented five different ways.
• AI features felt bolted on. Each AI use case was a separate modal with a different pattern. The team was about to ship a ninth without any shared language.
• Custom-product orders were a black box. The custom-printed line is the highest-margin category — and the most operationally complex. Artwork approvals, MOQ checks, supplier handoff, and proof-cycle states were tracked in Slack, not the system.

I resisted the pull to start redesigning screens. For the first three weeks I did an audit of every component, pattern, and AI touchpoint across the eight modules — shipped screens, Figma files, supplier-portal flows, and conversations with the 12 engineers actively building. The audit produced 240 distinct UI "things" that needed to become ~60 canonical components.

Then I sequenced the work in three parallel tracks that kept engineering unblocked while the system got built:

• Track A — Foundations (sprints 1–3): tokens, typography, spacing, color, iconography. Shipped to Vue.js as CSS variables so engineers could adopt immediately, ahead of component work.
• Track B — Core components (sprints 2–8): buttons, inputs, tables, modals, cards, empty states. Each component shipped with variants, tokens, dark mode, and a Figma↔Vue parity review.
• Track C — AI patterns (sprints 4+): a canonical pattern set for AI suggestions, confidence scoring, "why this?", and overrides — applied across every AI touchpoint in the product.

The system is built on three layers of tokens — primitive (raw hex, raw px), semantic (brand.primary, surface.raised, text.subtle), and component (button.primary.bg, table.row.hover). Engineering consumes the semantic layer. Design never references the primitive layer in a component. Theming, density, and a planned customer-facing portal all become config, not rework.

Component architecture is Figma Auto Layout with semantic variables and booleans — every component is one master with variants for size, intent, state, density, and theme. Replaced 240+ one-off "things" with 64 canonical components covering 100% of the product.

A 16,000-SKU catalog with seasonal demand, multi-warehouse stock, and a custom-print operation generates more decisions than any operator can keep in their head. The AI work isn't decoration — it's how the team makes those decisions on time.

Rather than design eight bespoke AI experiences, I defined a shared "AI cell" pattern with four consistent parts: the suggestion, confidence, "why this?" explainer, and accept / edit / dismiss actions. Every AI surface in the product is a composition of those parts — so users learn the interaction once and trust it everywhere.

"The AI shouldn't feel like a feature. It should feel like the product thinking with you. That means the same shape, the same voice, the same 'why this?' link — everywhere." — Design principle in the AI pattern guide

The custom-printed-products line is the highest-margin category and the most operationally complex. A single order can involve: customer artwork upload, MOQ and material checks, an automated proof, a customer revision cycle, supplier handoff, a press scheduling slot, sample approval, and bulk run scheduling — across multiple suppliers depending on the substrate.

I designed it as a single timeline view per order rather than the modal-stack the original product was heading toward. Every state is visible. Every blocker is attributed to a person or system. The customer-facing proof emails are generated from the same data — so what the operator sees and what the customer receives are the same record.

Key decisions:

• One timeline, not five tabs. Operators were context-switching between artwork, supplier, and customer threads. The timeline collapses that into a single ordered surface.
• Proof state is explicit, not implicit. "Awaiting customer approval" is a first-class state with an SLA, not a status anyone has to infer from email.
• Supplier handoff is a button, not a copy-paste. Eliminated the manual brief that was being assembled from three places for every order.