Work2026

Reductivist

A minimalist goods brand selling a handful of well made objects, where the real commerce problem was resisting the urge to add a fourth product to the homepage.

Role
Design and build, end to end
Year
2026
  • Next.js
  • Stripe
The Reductivist home page, showing a hero carousel above a three item product grid.

Reductivist sells three things and calls that a catalog. Most commerce templates assume growth toward more SKUs, more categories, more filters, and apply that assumption from day one, which makes three well made objects look like an unfinished store rather than a finished one.

The problem underneath the brief

A catalog this size does not need a category nav, a filter sidebar, or a comparison table, and building those in anyway because commerce sites are supposed to have them produces a homepage that apologizes for its own size. The actual brief was smaller than a commerce platform expects: sell three objects well, and do not let the platform's assumptions about scale outgrow the catalog.

3

Products at launch

A cross pendant and two utility tools, published with nothing added to pad the count.

1

Hero carousel

Lifestyle and product photography share one slot instead of splitting into a gallery nobody scrolls.

0

Category pages

A flat grid, because a browse by category nav solves a catalog size this store does not have.

How it is built

Next.js on the front end, with the image pipeline carrying most of the design weight since the photography is the product pitch. Stripe handles checkout directly rather than sitting behind a full commerce platform, which keeps the store's entire technical surface proportional to three products instead of the thousand a typical platform is built to expect.

The flat product grid showing all three Reductivist objects with no category navigation above it.
Three products, one grid, no category nav standing between a visitor and the thing they came to look at.

The commerce decision that mattered was the one made by omission. A platform with filters and comparison tables spends its interface budget solving a browsing problem this catalog does not have yet, and a store that size inherits that unused complexity as clutter rather than capability.

What I would keep

Resisting the instinct to build category infrastructure before there is a catalog that needs it. The store can grow into a bigger platform later; it should not carry one's assumptions now.