Designing an eCommerce OS from 0 → $3.6M ARR

A shipment moves stock from a supplier order or one warehouse to another, or to Amazon. The process has to be followed to the letter. Up to five questions shape each one: where it ships from, whether it crosses a border, boxes or pallets, whose carrier, and who labels the cartons. Together they make 48 paths and four ways to book freight.

Ely, Skupreme's founder, and I ran the research and the build over a run of sprints. We read Amazon's documented rules. We drew on the eCommerce business the team ran in-house for testing and on its supply chain experts, and filled the gaps with videos and published processes.

Most of the work was documentation, before AI prototyping existed: one checkbox could change the entire flow. Some steps need several kinds of information, some wait on another party to respond, and some need documents or a signature, so we mapped every action to the moment it happens and the person responsible for it.

Multi-brand operators outgrew Skupreme's account model. It was built for one brand per account, so an operator running 25 brands managed 25 accounts, and the single term “organization” stood for brands, groups, suppliers and warehouses alike. In billing, each brand had its own payment methods, and no one could tell which one a charge would come from.

I split the model into two levels. A parent company holds the wallet, the subscription and the users, with roles scoped per module; each brand holds its catalog, orders and integrations. Each level has its own settings and summary view, with switching in the top bar. Rules for joining, leaving and deleting a brand keep every charge tied to one source.

The split was my call. Its main cost was engineering time: it meant a large refactor, which slowed the release. Once billing had one structure, tickets about balances, wallets and permissions dropped, and customer success no longer had to set them up by hand.

With no other designer, the critique came from the team. Designs went through an internal review with the product team, then to engineering, who checked them against the data we had and what could ship on time, and sometimes to the wider team and customers. Every decision was recorded in a handoff format the developers worked best with. We kept improving that process, and it is a large part of why we shipped as much as we did.

Early on, before I knew the domain, I deferred to the team's structural proposals over my own judgment, for example where a new feature should live. The result followed individual mental models rather than one design, and drew complaints about navigation. The lesson I kept is to think about the whole product, even when working on a single detail.

I'd change two things. I'd start replacing our custom design system earlier and do it gradually, because keeping it cost us time and quality. Rebuilding a design system or a website all at once takes long and leaves things broken. And I'd hold regular customer conversations, separate from feature work, to keep a broad view of how the product is used.