What this is
This section exists for one reason: technical work for ecommerce gets better when the person doing it has actually run an ecommerce business. Listings, supplier files, photography, fulfillment edge cases, customer expectations, and the small operational decisions that never show up in a code review. Those are the things that separate a generic implementation from one that fits how the business actually behaves.
I run a few ecommerce brands alongside the technical work. The point isn’t to flex storefronts. It’s to keep the operator perspective close to the build.
Brands I run
Ophion
A premium product brand: positioning, store setup, content, and the long tail of small operational decisions.
End-to-end operator role: positioning, photography, copy, supplier relationships, fulfillment setup, pricing tests, and the steady stream of small choices that end up defining a brand more than any single decision. The store runs on Shopify with custom theme work and a handful of internal tools I built around it.
What this teaches Ecommerce isn’t checkout code. Catalog structure, content discipline, and operational habits all matter long before the technical layer does.
TheWayOfSake
Specialty ecommerce where information quality, trust, and product detail shape the buying experience.
A category where customers need context before they can make a decision: producer notes, tasting profiles, food pairings, and clear distinctions between similar-looking products. The store treats content as a first-class product attribute, not page filler, and the catalog is structured to support filtering by the things people actually ask about.
What this teaches Specialty products need structured content and careful presentation, not generic product-page filler. The data model is the brand.
KimonoKopen
Visual, variation-heavy ecommerce where catalog complexity grows faster than it looks like it should.
Hundreds of unique items, each with its own photography, condition notes, sizing, and provenance. The operational challenge isn’t the storefront; it’s the workflow from intake to listing. That’s where most of the internal tooling on the rest of this site came from.
What this teaches Visual products need reliable listing workflows and a practical system for managing details across inventory and presentation.
Governor
A smaller, design-led product brand used as a sandbox for storefront and content experiments.
Where the other brands prioritise operational consistency, Governor is where I try things: storefront patterns, content formats, checkout flows, packaging experiments. The lessons that stick get rolled into the other stores.
What this teaches Having a low-stakes brand to experiment in makes the high-stakes brands easier to run conservatively.
Why this matters for the technical work
A developer who’s done the operational side asks different questions. Where does the product data come from? Who updates it, and on what schedule? What does the customer need to trust before they’ll click buy? How does fulfillment change the workflow? Which mistakes get expensive later?
That perspective shortens the gap between business reality and the system that ends up running it. The work starts from how the operation actually behaves, not from a generic technical pattern, and the tools tend to fit the operator who has to use them every day.