Disciplines 03 · E‑commerce

Storefronts, built from scratch

Digital storefront concepts focused on product presentation, hierarchy, browsing and checkout interaction. This page opens by asking whether a custom build is even the right answer for a given business — a question worth exploring honestly rather than assuming yes.

Shape: Category and product pages, search or filtering where the catalogue needs it, the basket, and the handoff to a provider's checkout.
Payments: Never built from scratch. A provider's checkout, kept separate — a payment layer is its own discipline entirely.
Approach: Scoped before it starts, iterated as it goes, finished rather than abandoned. A real catalogue migration would need its own separate treatment.
Accessibility: Grid to basket operable by keyboard, walked by hand rather than only scanned.
Source: The storefront, the analytics and the repository — three readable files behind every build.

01 · The decision

Does a custom store earn its complexity?

Often, no. Marketplaces and hosted platforms handle checkout, payments, tax and fraud better than anything built from scratch, and a small merchant who picks one is behaving rationally rather than lazily. The interesting question is not which is better in the abstract. It is which of these two a given business actually is — and the honest version of that question has a side where custom loses.

the case for a marketplace

A marketplace or a hosted platform is the right answer

The business is still finding out whether the product sells at all.
The customer is already searching on the marketplace, not for the brand name.
The catalogue changes daily and somebody in the building has to be able to change it.
The risky part of the business is payments, tax and returns — not how the shop looks.
The business needs to be selling in weeks, and a build is months.

the case for a custom build

A custom storefront earns what it costs

The brand is the product, and a theme makes it look like everyone else who bought that theme.
The buying journey is not grid, product, basket — it is a configurator, a consultation, a subscription, a made-to-order form.
The platform's plan, its apps and its per-transaction cut have quietly become a rent that cannot be left.
The store has to be operable by keyboard and readable by a screen reader, and that has to be demonstrable.
The customer relationship, the data and the domain need to be owned rather than sublet.

If three of the five on the left describe a business, that is worth saying plainly, and naming the platform that fits better. That is not modesty. A store built for a business that needed a marketplace is a store that fails — and it fails with the builder's name on it.

02 · What is in one

A shop touches more systems than anything else I build

Which is why it is worth being exact about where the storefront ends. Six things a custom store is made of, and one of them is a boundary rather than a feature.

the journey

Grid, product, basket, and then a wall

Everything up to the basket is designed as one piece with the brand. The step after it is a provider's, and the wall is drawn on purpose rather than blurred.

payments

The payment layer is never hand-built

Tax across borders, fraud scoring, chargebacks, PCI scope — that is somebody's full-time job and it is a discipline of its own. Anyone offering to hand-build it is offering a liability with a nice interface on it.

the states nobody demos

Out of stock. One left. That variant does not exist.

A basket that emptied itself. A filter that returns nothing. Every one of these is a real screen a real shopper hits, and every one of them is drawn.

variants

Only the combinations that actually exist

Size, colour, finish. The ones that can't be bought are shown as unavailable rather than hidden, so nobody picks their way into a dead end and blames themselves for it.

the relationship

The customer list is owned, not sublet

Domain, hosting, analytics, repository and the customer relationship itself, in order from the first week. Leaving a platform later is a migration chosen rather than one whose price is discovered on the way out.

the catalogue

Migration is understood after a look, not before

Moving an existing catalogue is real work whose size nobody can know until somebody opens the data. It's a separate exploration in its own right, not something to assume away.

03 · The concession, and the gap

What a platform does better than a custom build

Checkout, and everything behind it. On a custom store those are still never hand-built: the checkout is a provider's, kept separate, and the build stops at the handoff to it.

What no platform ships by default is a store that works for someone who is not using a mouse. That is a build decision rather than a plan tier, and on a custom store it is a decision made in the open instead of one that gets inherited — every control reachable by keyboard, focus visible everywhere it lands, quantity and variant changes announced rather than silently applied, and the whole path from product grid to basket walked by hand.

Built to WCAG 2.1 AA practice, which is a description of how the work is done and not a legal opinion — no badge here, and no legal claim either. The test is one that runs on any shop: put the mouse down, press Tab from the first product to the basket, and see whether it finishes.

04 · What I test for

What's part of the build, and what I leave for another project

Same size, same weight, both columns. On a store the right-hand column is longer than on any other page here, because a shop touches more systems than anything else here explores.

Part of the build

Art direction made for the brand, not adapted from a theme.
The storefront itself — category and product pages, search or filtering where the catalogue needs it, the basket, and the handoff to a provider's checkout.
The states nobody demos: out of stock, one left, a variant that does not exist, a basket that emptied itself.
Every step from grid to basket operable by keyboard, tested by hand.
A performance budget set at the start and measured again at the end, on a catalogue the size it would actually be.
Structure ready for a second language and a second currency, even where none exists yet.
Full source, readable end to end.
Real iteration, not a first draft called final.

Outside this exploration

The payment provider, the tax engine and the fraud layer. Those are third-party services kept separate, each its own exploration.
Stock, warehouse, accounting or shipping systems, and any bridge to one — each its own exploration, never assumed.
Catalogue data entry, and product photography.
Migrating an existing catalogue — real work whose size can't be known before the data is seen, and its own exploration entirely.
Ongoing merchandising, campaign pages and seasonal changes once a build is finished.
Marketplace listings, feeds and channel management.
Any claim about sales, order value or conversion. These are concept builds, not measured storefronts.

05 · The objection

The trade-off worth naming honestly

Is a custom store harder to change later?

Parts of it, yes, and that is the honest trade. Adding a payment method or a shipping rule on a hosted platform is a switch; on a custom store it is work.

What that buys is that nothing about the design, the buying journey or the customer data is decided by a plan tier, and none of it is rented. The domain, the hosting, the analytics, the repository and the customer list stay in order from the first week, so leaving is a migration chosen rather than one whose price is discovered on the way out. The store is plain files and a provider's checkout — readable end to end, with no plan tier standing between the design and what it can do.

06 · The work

What the portfolio does and does not show

There is no store in the ten you can buy something from. The nearest is a product-led build with a grid, product cards and a basket that counts — and no checkout behind it, so I am not going to call it a shop. What the three below do show is catalogue work: how a set of things is laid out, priced on the page and made legible at a glance.

The Root & Ritual build — a product grid with a batch-limited range and a basket counter

e‑commerce

See it in the ten builds

There is no checkout in the ten, but the catalogue thinking — states, variants, restraint under a grid — is already running. The projects show the same discipline applied.

explore the work

The other three

All four disciplines

01WebsitesThree files, no build step 02Mobile App DevelopmentiOS and Android, explored as one job 04Graphic DesignIdentity systems, advertising and campaign work