Case study · Retail and e-commerce: A storefront where each work is one of one

01The challenge

An original painting is a stock-of-one product that must never be sellable twice, and the moment it sells its page has to stay up, because sold work is the strongest evidence a studio has. Prints behave like ordinary retail. Commissions are not products at all: they are a conversation that starts with a brief and a budget. Most hosted store platforms make the first case awkward, the third impossible, and all three look identical on screen.

02What we built

A Next.js storefront over a managed PostgreSQL service, with the catalogue modelled the way it actually is: collections of works, works with their own images and availability, prints, and separate records for commission requests and enquiries about a specific piece. Payment is a hosted checkout session with a webhook that marks a work sold once the payment settles, so availability is decided by the payment provider's confirmation rather than by the browser that started it. Sold works keep their page and wear their status.

The interface was designed as gallery architecture. The only chrome a work receives is a wall label — flush-left metadata under a hairline rule — and there are no cards, borders or shadows around art. A variable display face is set at extreme width and weight for headings, so type is the second material on the wall. Two accent colours exist: one for links and focus, one reserved entirely for the sold state. All other colour arrives from the paintings.

Around the shop sit the parts a working studio needs: exhibitions, press, a newsletter signup, a wishlist, an account area, and the shipping, returns and policy pages someone buying a physical object expects to read. Search engines and language models get a sitemap, a robots policy and a plain-text summary of the site.

03The outcome

The studio publishes a work, says whether it is available, and the storefront does the rest, including refusing to sell it twice. Commissions and enquiries arrive as records rather than as email, so a request has a state instead of a thread. The application runs on our own host; the database, file storage and the admin the studio edits in are a managed service, which is what keeps the day-to-day running of it out of our hands and theirs.