Modern Atelier: one multi-vendor marketplace, three very different users
A multi-vendor marketplace is really three products wearing one domain: a storefront for customers, a back office for vendors, and a control room for admins. The Modern Atelier — an architectural-tailoring label whose catalog runs from raw-silk shirts to a sculptural overcoat — ships all three as separate portals over one shared catalog and order pipeline, so a listing a vendor creates is the same listing a customer buys and an admin moderates.
- Type
- E-commerce · multi-vendor marketplace
- Stack
- Next.js · Clerk · multi-portal architecture
- Portals
- Customer · Vendor · Admin
- Status
- Live at modern-atelier.vercel.app
The problem: a marketplace splits every concern three ways
Single-seller shops are a solved problem; marketplaces are not. The moment several vendors sell through one storefront, every question splits: who owns a listing, who fulfils which slice of a mixed-vendor order, who resolves a dispute, and what each role is allowed to see. Build that as one app with a role switch and the permission checks end up scattered through the UI, where the next feature quietly forgets one.
The usual fix is to buy a marketplace platform and live with its opinions. I wanted to build the thing itself, because the interesting engineering isn't the storefront — it's keeping three permission models from leaking into each other while all three read and write the same products and orders.
The storefront: an archive to browse, not a grid to scroll
Customers land on the current collection — A/W 2024, “Physics of Form” — and move into curated series: Archive, New Essentials, Raw Fiber. The shop is filterable by category (outerwear, bottoms, knitwear, accessories, tops, dresses) and sortable by best-selling, newest, or price in either direction; every product has its own page and its own URL. Search lives in the header, and an “Atelier AI” assistant sits in the corner of every page.
The cart — titled “Archive of Selections”, because the brand voice runs all the way down — shows subtotal, taxes, and shipping calculated at checkout, offers a “complete the archive” cross-sell, and advertises complimentary shipping above a spend threshold. None of that is exotic. What matters is that all of it renders from the shared catalog, so a vendor's price change is the storefront's price change with no sync step in between.
Vendors and admins walk through the same door
Authentication is Clerk — sign-in and sign-up pages, one identity per person — and which portal opens after login depends on that identity's role. Vendors get a back office for their own listings, inventory, and incoming orders, scoped so they see only their slice. Admins get the whole marketplace: vendor onboarding, catalog moderation, and order oversight across every seller.
Neither back office is reachable without an account, which is why a visitor to the demo sees the storefront and nothing else. That's the correct behaviour for a marketplace and an awkward one for a portfolio; I've kept it correct. The visible trace of the vendor flow is in the catalog itself: alongside the tailoring sit listings that don't belong to the fashion line and carry generated URL slugs — a soy candle, an oak serving tray — which is the shape you get when vendors add products themselves rather than the catalog being seeded.
One catalog, three permission models
The architecture is portal-separated, not role-switched: three sets of routes, three navigations, three permission checks, one data layer underneath. A customer route never imports vendor logic; a vendor route can't render an admin control by accident, because the admin controls don't exist in that part of the tree. That's a blunter tool than fine-grained feature flags, and blunt is what you want when the failure mode is a vendor seeing another vendor's orders.
The trade-off is duplication — three product cards, three order lists, three headers — which I accepted deliberately. Shared components carry shared assumptions, and the assumption “this user may see this field” is exactly the one that must not be shared across portals. Where duplication was purely visual, the components are shared; where it touched what data is shown, they aren't.
Build notes
Next.js throughout, with Clerk handling identity so the app never stores a password. Product URLs are slug-based and stable, and the storefront ships a mobile bottom navigation — home, search, shop, account — because a fashion catalog is browsed on phones far more than on desks. The bag badge in the header and the cart summary read the same cart state, so the count a customer sees while browsing is the count they see at checkout.
The brand voice was treated as a requirement, not decoration: the copy, the section names (“Tactile Physics”, “The Manifesto”), and the serif-and-mono type pairing all belong to the label, and the UI stays out of their way. A marketplace that looks like a template tells vendors their brand will look like a template too.
Honest limits
The Modern Atelier is a portfolio build, not a marketplace with a seller community behind it, and I'd rather say so. The storefront, cart, and authentication are live and public; the vendor and admin portals exist behind login and are something I walk through on a call rather than something you can click into from here.
What I'd add next is vendor payouts and dispute tooling — the parts of a marketplace that only matter once real money moves between three parties, and the parts that decide whether vendors trust the platform enough to stay on it.