Multi-Store Grocery Marketplace

Project overview

We built an online grocery marketplace for a startup partnering with independent grocers, butchers and specialist food shops in its service area. Shoppers browse every partner store from one storefront, put items from several stores in one basket, choose a delivery slot, and receive one consolidated delivery.

The engagement covered marketplace discovery, the Next.js storefront, Node.js services, Postgres data model, a picker app for store staff, the admin console and store onboarding. It is part of our eCommerce app development work in retail and eCommerce.

The client and the challenge

Partner stores had very different systems: some exported stock from a till, others kept no digital inventory at all. Items went out of stock during the day, so orders often could not be picked as placed. The startup also had limited drivers per time window and no reliable way to stop over-booking busy evening slots.

It needed one basket across stores, accurate slot availability, a fair way to handle substitutions and weighted items like meat and produce, and clean settlement so each store was paid correctly for what it actually supplied. Store owners also wanted simple tools: most had no time for training and would only adopt something that fitted around serving customers at the counter.

Solution architecture & delivery

The Postgres data model separates a shared product catalogue from store listings, so the same item can be offered by several stores with their own price and stock. Stores with till exports sync stock on a schedule; others update availability through the picker app. Search in the Next.js storefront groups results by product and shows which store supplies each one, and the basket is split into store sub-orders behind the scenes.

Delivery slots are modelled as capacity per zone and time window, based on driver shifts and how long picking takes at each store. When a shopper selects a slot, the Node.js slot service places a short reservation in Postgres inside a transaction, so two shoppers cannot take the last place at once. Unpaid reservations expire and return capacity automatically, and admins can close slots or add capacity when shifts change.

Store staff pick from the picker app, which lists sub-orders by aisle. For an unavailable item they choose a substitute from similar products; the shopper gets a notification and can accept or reject before the order closes. Weighted items are authorised at an estimated price and captured at the actual weight, so the shopper only pays for what is packed.

Payments go through a payment gateway with authorisation at checkout and capture after picking. The settlement service calculates each store's share from picked quantities, less commission and refunds, and produces payout reports. Caching and load handling for evening peaks followed our high-traffic architecture guide. Refunds for rejected substitutions or missing items are issued against the same payment automatically, and the shopper sees an itemised adjustment on the final receipt.

Key features we built

• Single basket across several stores, split into store sub-orders
• Shared catalogue with store-specific prices and stock
• Delivery slots with zone capacity and race-safe reservations
• Picker app with aisle-sorted lists and substitution suggestions
• Shopper approval of substitutions before the order is closed
• Weighted items authorised at estimate and charged at actual weight
• Store settlement with commission, refunds and payout reports
• Promotions, coupons and repeat-basket reordering

How we delivered it

1. Discovery. We visited partner stores, reviewed their stock data options, and mapped slot capacity with the delivery operations lead.
2. UX and prototype. Multi-store basket, slot selection and substitution approval flows were tested with shoppers and store staff before build.
3. Build. Two-week sprints delivered the storefront, slot and settlement services, picker app and admin console, with store data onboarded in parallel.
4. Pilot and roll-out. A handful of stores and one delivery zone went live first, letting us tune picking times, slot capacity and substitution rules before adding more partners.
5. Support. Ongoing support covers new store onboarding, zone expansion and seasonal promotions. Store feedback sessions feed a regular backlog of picker app improvements.

Technology choices

• Next.js — server-rendered category and product pages for search visibility, with a fast client-side basket and checkout.
• Node.js — event-friendly services for slots, substitutions, notifications and settlement running alongside the storefront.
• Postgres — transactional guarantees for slot reservations and payments, plus a relational model for shared catalogue and store listings.

Outcomes

• Shoppers fill one basket from several local stores and receive a single delivery
• Evening slots can no longer be over-booked beyond real driver capacity
• Substitutions are agreed with the shopper instead of surprising them at the door
• Weighted items are charged at what was actually packed
• Each store is paid from picked quantities with clear payout reports
• Stores without digital inventory can still take part through the picker app

FAQ