Apparel E-Commerce Platform

The problem

The client began as a local Ohio clothing-delivery service and grew past what its tools could handle: first across Pennsylvania and New York, then into its first international orders. 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 that three-state 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

Product strategy and architecture for the platform were led 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, the data model was structured 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 three US states (Ohio, Pennsylvania, New York) into international orders from the UK, Australia, and New Zealand, without architectural rework.

The results

Replacing the disconnected tools with one lifecycle changed the day-to-day math of running the business:

• Ordering dropped from days to hours. Procurement that used to take multiple days now closes in hours.
• Fulfillment reconciliation went from days to near-instant. Confirming that everything ordered matches everything received, once a multi-day manual job, is now automatic.
• Reorder timing became a decision, not a guess. The platform surfaces how long each distributor takes to fulfill, how long items sit in inventory, and the best window to reorder.
• Customers stopped having to ask. Where buyers once asked, double-asked, and triple-asked whether a product was still available, they now check real-time stock and place the order themselves.

How it was built

The same delivery model built for Arc Katalyst applied here: seven defined roles executing within the CH(Ai)SE governance harness, with 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 the 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, it was unclear 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 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 common mistake in this situation is choosing tools by preference instead of stage, and either shipping slowly on a stack not yet needed, or getting stuck on one that's been outgrown.