An operating system for commerce.

Potter is an operating system for commerce. Software that *runs* a business, not just builds a storefront. A merchant describes what they sell, Potter stands up the store, then handles the unglamorous parts: orders, payments, reconciliation, and customers. I led design across the whole platform and built the front-end in code, from the data model up to the last interaction state. One designer owning the money model, the information architecture, and the components kept the system coherent instead of splintering into three dialects of the same idea.

Off-the-shelf commerce tools assume the easy path: a card payment online and a clean state machine. Real merchants here run on **cash-on-delivery and reference-less bank transfers**, money that lands messy, late, or not at all. A buyer sends ₦24,500 with no order number attached. A rider collects cash days after the sale. The hard, valuable work was never the storefront. It is matching that money to the right order and chasing the balance that never arrives.

The market was racing to ship one thing: a prettier storefront builder. But a storefront is the part that already works. Merchants bleed money in the operations underneath it, and nobody was designing for that. I spent the first weeks watching merchants run their day, not sketching screens. The pattern was the same everywhere: the sale was easy, the reconciliation was a notebook and a thumb scrolling a bank app. So I pointed the product at the gap and made the unglamorous parts the centre of the design.

An order is not done when it ships. It is done when the money is in. So fulfilment is a real state machine with the cash event as a first-class transition: confirm, collect cash, reconcile the transfer, fulfil, settle. The COD branch is built in, not bolted on, because cash on delivery is the default path here. Designing it as one path forced honest answers to the messy questions: a rider collecting partial cash, a transfer arriving before the order is confirmed, a buyer paying for two orders in one lump. Each is a transition in the model, surfaced as a clear next action rather than a dead end.

That one loop then powers one system seen from three sides. Cloud is the operator’s console. Studio is where a merchant describes a business and watches it get built, then operated. Admin is the cross-tenant view the platform team works from. An order means the same thing in all three, so nothing is re-explained when a merchant moves between them.

Everyone was shipping prettier website builders. The unmet job was operations, so the hard call was resisting the storefront. It demos well and everyone asks for it. But a builder is judged on its themes, an operator on whether the money is right at the end of the day. I optimised for the second test, and three moves carried it. Reconciliation matches a reference-less transfer to an open order by amount, time window, and sender, then asks the merchant to confirm only the one ambiguous case. The COD lifecycle is a real state machine, not a status badge. And customer memory carries a buyer’s history across orders.

A working order-to-money loop on real rails, across a platform a small team can run: 21 surfaces shipped across three products, with order to COD to reconcile to settled running end to end and live.

What I would change: I began in the storefront and almost shipped a prettier builder before research forced the operator pivot. The lesson that stuck is to design the money path first, then everything else is decoration. Once reconciliation and the COD lifecycle were the spine, the rest of the platform fell out of them cleanly. If I started again I would skip the storefront sprint and spend that time with merchants at the moment the money does not match.