Apparel E-Commerce Platform

The problem

The client had grown past what their existing systems could handle. Procurement, inventory tracking, shipping logistics, and sales were running through disconnected tools that didn't share a data model. Reconciling them was manual, error-prone, and getting more expensive every quarter. Expanding beyond their three-state operating footprint into international markets made the reconciliation overhead untenable.

They needed one platform that owned the entire lifecycle end-to-end. One source of truth from purchase order through settled sale.

The product decision

I owned product strategy and architecture for the platform end-to-end.

The central design decision was to model the platform around the operational lifecycle rather than around business functions. Most e-commerce platforms are organized by department — a procurement module, an inventory module, a shipping module, a sales module — with integrations between them. That structure inherits the same reconciliation problem it's supposed to solve.

Instead, I structured the data model around a single lifecycle: item → SKU → inventory position → order → fulfillment → sale. Every operational decision the business needed to make mapped to a state transition within that lifecycle. Procurement wasn't a separate system; it was the earliest states in the same lifecycle. Sales wasn't a separate system; it was the terminal states. The lifecycle was the platform.

This decision paid back most when international expansion hit. Multi-region shipping, currency handling, customs and duties, and inventory positioning across geographies didn't require new modules — they required extending existing states with new attributes. Growth became configuration, not architecture.

What shipped

A live, production-grade web platform running the client's day-to-day operations across:

• Procurement — purchase orders, supplier management, inbound tracking.
• Inventory — SKU-level positioning, stock levels across locations, reorder logic.
• Logistics — shipping workflows, carrier integration, tracking.
• Sales — order management, fulfillment, sales reporting.
• Multi-region operational support — extended from a three-state footprint into international markets without architectural rework.

How it was built

The same delivery model I built for Arc Katalyst applied here: five Claude Code agent roles executing within scope, with me as the human Operator owning every product and release decision. Ceremonies stayed traditional — sprint planning, refinement, retros, cards with story and acceptance criteria — and the three-tier action gate governed mid-sprint drift the same way it did on Arc.

What differed was the platform. V1 was built on Lovable, an AI-powered platform for React and Supabase applications — the right choice for shipping a production-grade V1 fast to a client with real operational needs. Under the surface, Lovable produces React + Supabase, which meant no architectural rework would be needed to graduate the platform to self-hosted infrastructure when the time came.

The critical PO discipline on client work is scope translation. A client stakeholder saying "wouldn't it be great if the platform did X" isn't a scope commitment yet — but it becomes one silently if the PO isn't structuring the conversation. A large share of my delivery work on this engagement was structured framing: what's a discovery item, what's an epic, what's a story, what's a nice-to-have with no engineering commitment attached. Structured framing turns client relationships into product relationships.

Current state

Live in production, running the client's operations. The platform is currently being migrated from Lovable's managed environment to self-hosted Supabase and Vercel — a maturity graduation as the client's operational scale and control requirements have grown. The product engagement continues in parallel, with new capabilities defined against evolving business needs.

What I learned

The delivery methodology transferred cleanly from a personal product to client work.

Going in, I wasn't sure how much of the Arc Katalyst governance model would hold up under client pressure — the scope conversations are different, the release cadence is different, the accountability structure is different. In practice, the five-role harness needed almost no adaptation. The role boundaries and the three-tier drift gate held. If anything, they mattered more on client work, where scope conversations happen faster and cost more when they go unstructured.

Tool selection is a product decision, not a technical purity contest.

Lovable was the correct tool to ship V1 to a paying client at speed. When the client's scale and operational control needs outgrew Lovable's managed environment, the migration to self-hosted Supabase and Vercel became the correct next tool. Neither decision was about the technology — both were about matching product infrastructure to product stage. The mistake I've seen other POs make in the same situation is choosing tools by preference instead of stage, and either shipping slowly on a stack they don't need yet, or getting stuck on a stack they've outgrown.