A storefront where vendors run themselves
A multi-vendor storefront where independent sellers manage their own catalog and orders while shoppers browse one unified store.
The brief, in specifics
- Industry
- Online Marketplaces
- Duration
- 16 weeks
- Cooperation model
- Time & materials
Client name withheld under NDA. Engagement details are shown to the extent our agreement permits.
The hard problem
- 01
Vendors had no self-serve way to manage catalog or orders, so every change went through manual back-and-forth and shoppers saw an inconsistent store.
A vendor wanting to change a price emailed it, and it changed when the email was read. The measurable consequence showed in the listings: vendors published in bursts when they had the operations person's attention and not at all otherwise, so the front page reflected who had emailed most recently, not what was new.
We built a vendor dashboard for managing listings and orders directly, and unified the customer-facing storefront so browsing feels consistent across every vendor.
How the pieces fit
- 01
Designed a self-serve vendor dashboard for catalog and orders
The dashboard's scope changed twice during the build as we watched what makers actually did with it, which is exactly what time and materials was for.
- 02
Unified product presentation across all vendors
The storefront normalizes vendor data into one image, size and delivery vocabulary, keeping vendor identity where it affects trust and nowhere else.
- 03
Automated payouts and order-status syncing
A cart spanning several vendors is one payment and several transfers through Stripe Connect, with commission computed per line item.
- 04
Rolled out to top vendors first, then the long tail
The ten largest vendors went first with the team watching them work, and the long tail followed once those ten had stopped emailing.
The system we were asked to build
Every vendor listing change was handled by hand. We shipped self-serve vendor tooling behind a unified shopping experience.
A curated storefront with about sixty independent makers, whose catalog changes all went through one operations person by email. That person was the constraint on the whole business: new listings waited days, stock was updated when someone got around to it, and the shop looked like sixty shops. The engagement was scoped to remove that queue entirely, not to make it faster.
Design & Build
Merchant Self-Serve Studio
Lets independent vendors upload items, track inventory and process orders on their own.
Vendors get a scoped dashboard that resolves against their own records server-side, so one merchant can't reach another's orders even by guessing an ID. Listings, stock and fulfillment all live where a vendor already checks for orders, and that's what stopped stock drifting: the update happens where the reason for it appears, instead of in a separate admin tool nobody opens.
- Server-scoped records: vendor isolation, not hidden UI
- Listings, stock and fulfillment in one place
- Stock updated where the reason to update it appears
One shelf, nine markets. The maker sets stock per market in one grid scoped to their own shop: sold-out cells in rose, the last few units in mustard, and one rule the storefront reads too.
Unified Customer Storefront
The shopper's side: bowls from many makers ranked from one search index, in one image treatment, one size scale and one delivery format, with the maker named only on the product page.
Brings listings from dozens of vendors together into one consistent, single-brand browsing experience.
The storefront normalizes vendor data into one presentation layer (one image treatment, one size vocabulary, one delivery-estimate format) so dozens of sellers read as one shop. Vendor identity survives on the product page, where it matters for trust and shipping, but nothing in the browse grid tells you which vendor a card belongs to. Search ranks across all vendors from one Algolia index.
- One image, size and delivery vocabulary across vendors
- Vendor identity kept where it affects trust and shipping
- A single cross-vendor search index
Automated Split Payouts
Handles multi-vendor cart checkout and automatically routes payments and commissions via Stripe Connect.
A cart spanning four vendors is one payment to the shopper and four transfers behind it, handled through Stripe Connect so the platform never takes custody of the funds. Commission is computed per line item, which is what makes mixed-rate categories work. Refunds reverse the specific transfer instead of the whole charge, and payout failures surface on the vendor's own dashboard.
- One shopper payment, per-vendor transfers via Connect
- Commission computed per line item, so mixed rates work
- Refunds reverse the specific transfer, leaving the rest of the charge alone
One basket routed to four makers as four parcels: one card payment, commission priced line by line at mixed rates, a transfer each, and a broken jar refunded against one maker's transfer only.
Phase by phase
Phase 1: Merchant Workflow Audit
Vendor Operations Analysis
Audited manual vendor onboarding and catalog update bottlenecks across about sixty independent makers.
- Merchant Portal Audit
- Multi-Vendor Data Schema
- Operational Bottleneck Report
Phase 2: Merchant Cockpit Design
Self-Serve Vendor Studio UI
Designed an intuitive self-serve dashboard allowing independent vendors to manage products, pricing, and order fulfillment.
- Merchant Cockpit UI
- Bulk Catalog Importer
- Inventory Management Specs
Phase 3: Automated Payout Engine
Split-Payment & Sync Engineering
Built automated split-payment processing and order status synchronization using Stripe Connect and GraphQL APIs.
- Split Payout Engine
- Multi-Vendor Order Router
- Stripe Connect Integration
Phase 4: Pilot & Merchant Rollout
Staged Merchant Onboarding
Rolled out to the ten largest vendors first, then to the long tail of the shop's roughly sixty makers, with a more consistent catalog and 64% lower support load.
- Pilot Performance Report
- Merchant Onboarding Guide
- Production Launch
Five steps from application to first listing in the operations console, with the traders in the queue, the step each has reached and who each one is waiting on.
What it carries now
−64%
Vendor support load
+3.2x
Listings published/week
Unified
Catalog consistency
Support load is the operations inbox's own count of vendor requests, comparing the two months after full rollout with the two before. Listings published per week is measured across all vendors, so the figure includes the long tail that was previously publishing almost nothing. Catalog consistency is a qualitative claim, not a metric.
Client name withheld under NDA. Figures are approximate, drawn from the engagement’s own reporting.
What the architecture settled
Self-serve vendor management reduced operational support tickets by 64%.
The support load was one queue, and removing the queue removed it. Making the operations person faster would have moved the number by a fraction of this.
Automated catalog sync increased weekly published vendor listings by 3.2x.
Publishing rose most in the long tail, which had never really been publishing to a schedule. It had been waiting for permission it no longer needed.
Unified customer-facing storefront presentation established single-brand cohesion across multi-vendor inventory.
Normalizing presentation while keeping vendor identity on the product page was the trade that made both possible: shoppers get one shop, makers keep their name.
How the work was run
- 01
A cross-functional team of 5 worked on a time & materials basis over 16 weeks, covering Vendor platform, Order management, Storefront. We ran daily standups with an in-house lead in the room, and a demo at the end of every sprint. Scope changed twice during the engagement, and both times the change was priced and agreed before work started.
Rollout went to the ten largest vendors first, with the team watching them use the dashboard instead of surveying them afterward. The long tail followed once those ten had stopped emailing. Time and materials suited it: the vendor dashboard's scope genuinely changed twice as we watched what makers actually did with it.
One product, nine markets
The shop used to look like sixty shops. Now every surface reads the same stock.
A maker's breakfast bowl in five glazes, stocked separately in each market. Pick a market and watch the storefront card, the product page and the maker's own grid resolve sold out, last few and in stock from one record. Switch tabs, or use the arrow keys once one is focused.
- Oat4
- Moss2
- Slate0
- Kiln white7
- Ember1
- UK stock record read
- One rule applied: 0 sold out, 1–3 last few
- Storefront card resolves
- Product page resolves
- Studio grid cell resolves
In stock as a line (14 units). Glazes: 2 in stock, 2 last few, 1 sold out.
Why they cannot drift: no surface keeps its own copy of stock. Before, a change was an email to operations and took effect when someone read it; now the maker edits the record in the studio, and everything else resolves from it. Unit counts are illustrative, and so are the step timings.
From a maker's edit to one shop and a transfer each
One operations inbox used to sit between every maker and the shop. Now a maker's change goes through a scoped API into the same records the storefront and the payouts read.
- 01 · SourceMaker studioListings, stock and fulfillment are edited where the orders already arrive, so stock changes where the reason to change it appears.
- 02 · APIGraphQL, scoped server-sideEvery query resolves against the signed-in vendor's own records, so one maker can't reach another's orders even by guessing an ID.
- 03 · EngineOrder router & split payoutsA cart becomes one parcel and one Stripe Connect transfer per vendor, with commission computed per line item.
- 04 · StatePostgreSQL catalogue & ordersVendor data is normalized into one image, size and delivery vocabulary before anything reaches a shopper.
- 05 · DeliveryNext.js storefront & one indexSearch ranks across every vendor from a single Algolia index; vendor identity appears on the product page and stays off the browse grid.
What one maker's account can reach
Vendor isolation & money movement
Isolation lives on the server, not in the UI
A maker's dashboard resolves against their own records server-side. Guessing another vendor's order ID reaches nothing, because the query never resolves outside that maker's records.
The platform never takes custody of the funds
A basket across several makers is one payment to the shopper and one transfer per maker through Stripe Connect, with commission computed per line item.
A refund touches only its own transfer
Refunds reverse the specific transfer the line belongs to instead of the whole charge, and a payout that fails surfaces on that maker's own dashboard.
Do your vendors still email in every price and stock change? Scope your build in three minutes.
Scope your buildNearby engagements
Data & AnalyticsA checkout that stopped losing sales to a 6-second load
Profiling found the real bottleneck behind a slow checkout (an N+1 query and an oversized bundle) and tuned both, with before-and-after metrics locked in as a baseline against future regressions.
E-commerce & Retail · 5 weeks
Web PlatformsA reader people finish, and a library that remembers where they stopped
A reading platform for a comics catalog: a browse surface people can actually navigate, a reader that gets out of the way, and a history that puts everyone back on the page they left.
E-commerce & Retail · 18 weeks
Web PlatformsOne number, a whole handset, and a database that keeps up with 125 brands
A metered IMEI lookup service that turns fifteen digits into a device, its specifications and its status. It's sold three ways to three audiences and backed by a device database that maintains itself.
Consumer Electronics · 22 weeks
Let's talk
Running a large platform, shaping a first MVP, or getting a product ready for a funding round? Tell us where you are. We'll shape the process around it, and stay with you after launch.
