Executive Summary

Lauren and Blair Steenholdt, co-founders of Mind of Man Ltd., were looking at a category the major food delivery platforms had quietly written off. Aggregators are built for chains: fixed menus, steady stock, thirty-minute delivery windows. None of that describes a home baker taking three days over a celebration cake, a market stall that sells out by eleven, or a producer shipping a single fragile jar of chilli jam across the country.

Net Solutions was brought on as a dedicated engineering partner to design and build Scoff, a double-sided marketplace where independent sellers list specialty, made-to-order and small-batch food, and buyers find it, order it, and receive it by click and collect, local delivery or post.

The brief was never a storefront. It was two connected experiences, buyer and seller, inside one product. It was two separate ordering engines, one for food that has to move within the hour and one for goods with a dispatch date weeks out. It was split payments that pay the seller and the platform automatically at the point of sale. And it was a dispatch engine flexible enough to handle a glass jar going three streets away and a multi-kilogram parcel going to another country, from the same store, on the same day.

We took the founders from early business model validation through to a live MVP on iOS, with a responsive seller web panel and an admin CMS the team could run the business from.

Client Snapshot

  • Company: Mind of Man Ltd. (product: Scoff)
  • Founders: Lauren Steenholdt and Blair Steenholdt
  • Industry: Food and beverage, online marketplaces
  • Geography: United Kingdom, with London as the launch market
  • Engagement model: Dedicated resource team covering business analysis, UI and UX design, web development, mobile development, HTML and QC
  • Platforms built: iOS application serving both buyer and seller roles, responsive seller web panel, admin CMS
  • Key integrations: Shutl API for local courier dispatch and live tracking, automated split-payment routing

What We Build

  • One account, two roles, so a trader who also likes to buy from peers never needs a second login
  • Two ordering engines, one real time and one calendar driven, because a sourdough loaf and a wedding cake are not the same transaction
  • Dispatch rules set per product, not per store, with vehicle restrictions to protect fragile goods
  • Automatic payment splitting, so sellers see their net payout before they accept the order
  • Custom orders brought in-app, with deposits, balances and an auditable message thread replacing DMs and email
  • An admin CMS the founders run themselves, without a developer in the loop for everyday operations

The Challenge

Picture wanting a jar of small-batch chilli jam from someone three streets away, or a custom-iced birthday cake from a home baker down the road. You cannot reliably find them. You cannot tell when they could actually deliver it. And once you do find them, you are paying a stranger through a direct message and hoping. That was the state of play for independent food sellers and the buyers who wanted to support them.

Sellers Looked Unreliable Through No Fault of Their Own

A buyer orders sourdough at 2 pm, not knowing the seller sold out at 11 am. Another expects next-day delivery on a cake that genuinely takes three days to bake and decorate. The seller ends up looking careless for honouring the way their own kitchen works.

Buyers Could Not Find What They Were Actually Looking For

Someone searching for a gluten-free celebration cake, a micro-batch hot sauce or freshly baked sourdough had nowhere to search that understood the request. Generic grocery taxonomies buried these products under irrelevant results.

Delivery Options Were a Surprise at Checkout

A buyer could add a fragile jam jar to a basket and only learn at checkout that it could not travel by motorbike. Or discover that a seller three streets away offered no local delivery at all, forcing an expensive postage charge on something they would happily have collected in person.

Sellers Could Not Trust They Would Be Paid Correctly

Between commission, card fees and other deductions, a seller had no clear picture of what they would actually take home from a sale. That uncertainty alone was enough to keep a home baker or market trader off a platform.

Buying and Selling Meant Living in Two Apps

A market trader who also buys from other independents had no single place to do both. Separate logins, separate apps, or a workaround. The dual role was treated as an edge case when in this community it is normal.

Custom Orders Lived in DMs and Email

Made-to-order requests were negotiated in unmonitored inboxes, with no payment protection, no deposit mechanism and no record either side could rely on if something went wrong.

Our Approach

We worked as a dedicated engineering team alongside Lauren and Blair rather than a fixed-scope supplier, which meant the product decisions and the technical decisions were made in the same room. Four strategies shaped the build.

  • Domain and entity modelling first: We modelled dual-role user accounts, unified profile state toggles and a flexible three-tier taxonomy for niche food inventory before writing feature code, because retrofitting a dual-role identity model later is close to a rewrite.
  • Two transaction pipelines, not one with exceptions: We architected an asynchronous real-time notification loop for ASAP orders and a separate calendar-driven lead-time engine for made-to-order goods. Forcing both through one checkout would have compromised each.
  • Fulfilment as a matrix, not a setting: We engineered a product-level dispatch engine covering click and collect, local courier and postage, with vehicle-type constraint rules, and integrated the Shutl API for automated courier matching and live GPS tracking.
  • Payment splitting at the gateway layer: We designed payout routing that calculates and divides seller earnings, platform commission and processing fees dynamically at the point of sale, so reconciliation never becomes a manual job as volume grows.

The Solution

Five systems, each one built around how independent food sellers actually trade.

01.

Unified Double-Sided Account Architecture

We engineered a single account model that lets any user switch between buying and selling inside the same application. Sellers build a dedicated store profile with opening hours, multi-location support and their own story. Buyers browse and purchase with no separate login and no second app to download. The toggle is a state change, not a different product.

02.

ASAP and Scheduled Ordering, Built as Separate Engines

Scheduled items run on calendar-driven lead times, so a three-day bake is visible upfront rather than discovered after the order lands. ASAP orders run on a real-time notification loop: the seller receives the request, responds with a live preparation time, and the buyer confirms before payment is processed. Orders placed outside active store hours are blocked automatically, which keeps sellers from being held to commitments they never saw.

03.

Product-Level Dispatch and Calendar-Based Delivery Slots

We built a fulfilment matrix letting sellers assign click and collect, local delivery or postage per product, with vehicle-type restrictions so fragile goods never get matched to unsuitable transport. The Shutl API handles automated local courier matching and tracking. At checkout, buyers choose from delivery slots that reflect the seller’s live capacity, so the date they pick is a date that exists.

04.

Split Payments and Custom Order Deposits

Payment splitting calculates seller payout, platform commission and processing fees instantly as the transaction completes, with the breakdown visible to the seller rather than buried in a monthly statement. To bring custom work out of direct messages, we built an in-app pipeline where buyers request a tailored quote, pay a deposit at checkout, and settle the balance on completion, with the whole negotiation tracked in one messaging thread.

05.

Specialty Discovery and Social Curation

We engineered a three-tier category taxonomy with an admin approval workflow, so niche sellers can list products that no rigid grocery model would accommodate. Multi-attribute filters across dietary requirements, price, location and fulfilment method make those products findable, and built-in collection sharing lets buyers curate and pass on what they discover.

Impact

Availability Mismatches Designed Out

Live stock states and visible lead-time calendars stopped buyers from ordering what was already gone or expecting a cake before it could physically be made. Sellers stopped absorbing reputational damage for other people’s assumptions.

Specialty Products Made Discoverable

Purpose-built categories and multi-attribute filtering surfaced small-batch and niche goods that generic marketplace search had been burying, which is the difference between a listing existing and a listing selling.

Fulfilment Certainty Before Checkout

Buyers see only the dispatch options genuinely available for that product, that seller and that location. Removing the checkout surprise removes one of the most common reasons a food basket gets abandoned.

Financial Transparency for Sellers

Commission and fee breakdowns are visible before order confirmation, so a seller knows their net position on every sale. For a trader deciding whether a platform is worth the shelf space, that clarity is the whole argument.

A Dual Role Without Duplicate Accounts

Local producers can buy from their peers using the same profile they sell with. One account, one history, no workarounds.

Custom Orders with a Paper Trail

Deposit checkout and threaded messaging gave both sides an auditable record of what was agreed, what was paid and what is still outstanding on bespoke work.

An Operationally Independent Platform

The custom admin CMS lets the founders manage categories, approvals, users and reporting day to day without raising a developer ticket, which matters more to an early-stage team than almost any feature on the roadmap.

Why Net Solutions?

Built for a New Business Model, Not Adapted from a Template

A double-sided hyperlocal food marketplace shares very little with a conventional storefront. The data model, the ASAP workflow and the dispatch engine were designed around how independent food sellers actually trade, because there was no template that described it.

From Business Validation to Live Product

We were with Lauren and Blair from early model validation through wireframes, sprint-planned backlogs and full-stack development. Founders get a technical partner across the whole journey, not a team that arrives once someone else has written the requirements.

Comfortable with Marketplace Complexity

Split payments, commission logic, dual-role accounts and per-product shipping rules are precisely the edge-case-heavy requirements that expose the limits of off-the-shelf platforms. We handled them at the data-modelling stage rather than retrofitting them after launch, which is the only point at which they are cheap to get right.

A Dedicated, Embedded Team

Business analysis, design, web and mobile development and QC in one team, working with the founders sprint over sprint. No fixed-scope handoff, no gap between the people who understood the business and the people writing the code.

Building Something the Off-the-Shelf Platforms Cannot Hold?

Scoff exists because its requirements could not be configured into an existing platform. Dual-role accounts, two ordering engines, per-product dispatch and automated payment splitting are not plugins. If your product has that shape, the right conversation is an architectural one, and it is worth having before the build starts rather than after.

FAQs

What is a double-sided marketplace and why does it need custom development?

A double-sided marketplace serves two distinct user groups, buyers and sellers, often within the same account. Off-the-shelf e-commerce platforms assume one seller and many buyers, so requirements like switching between a buying and selling view, per-seller commission splitting and individual seller storefronts generally need custom development rather than a plugin or theme.

How does an ASAP food ordering workflow differ from a standard delivery order?

An ASAP order is confirmed in near real time instead of being scheduled in advance. The seller gets a live notification, replies with an actual preparation and delivery time, and the buyer confirms, cancels or opens a chat before payment is taken. The system also blocks ASAP orders placed outside the seller’s operating hours, which a standard scheduled checkout never has to handle.

Can a food marketplace app support different delivery options per product?

Yes. Click and collect, local courier delivery and postage can be configured at product level rather than store level, along with vehicle restrictions for fragile items, weight-based pricing and coverage zones from local to international. One seller can offer completely different fulfilment methods for different products in the same store.

How are payments split between a seller and a marketplace platform?

At the point of sale, the transaction is divided automatically between the seller’s payout and the platform’s commission, with card processing fees and any fee on the commission itself calculated in the same step. This removes manual reconciliation and delayed payouts, and it lets the seller see the net figure before confirming the order.

Does Scoff support custom or made-to-order food products?

Yes. A buyer submits a custom request to a seller with a description, due date and reference image. Once the seller confirms pricing, the buyer pays a deposit at checkout and settles the balance when the order is ready, with everything tracked inside the existing message thread between the two parties.

Can one person both buy and sell on the same marketplace account?

Yes, if the identity model is built for it. Scoff uses a unified account with a profile toggle, so the same user can run a store and shop from other sellers without a second login. Adding this after launch usually means reworking the core data model, which is why it belongs in the first architecture conversation.

How do you handle courier delivery in a hyperlocal marketplace app?

Through a courier API integration. Scoff uses the Shutl API to match local orders to available couriers automatically and to provide live GPS tracking, with vehicle-type rules preventing unsuitable matches such as fragile glassware assigned to a motorbike.

What should go into an MVP for a marketplace platform?

Enough of both sides for a real transaction to complete end to end: seller onboarding and listings, buyer discovery and checkout, the fulfilment options the category actually requires, and automated payment handling. Scoff launched on iOS with a seller web panel and an admin CMS, which gave the founders a working two-sided economy without building every planned feature first.

How long does it take to build a double-sided marketplace app?

It depends on how much of the complexity is structural. Dual-role accounts, multiple ordering engines, per-product dispatch rules and split payments each add architectural weight, not just screens. A phased approach works best: model the domain properly, ship a complete transaction loop on one platform, then extend. We can give a realistic range once we understand which of those elements your product genuinely needs.

DOUBLE-SIDED MARKETPLACE BUILDS

Is marketplace complexity holding your platform back?

Whether you are building a double-sided marketplace, working out split payments and commission logic, or designing fulfilment rules that off-the-shelf software will not bend to, there is usually an engineering answer. Tell us what the bottleneck looks like and we will show you how we would approach it.

OUR WORK

Related Success Stories

Results matter. Discover how our customized solutions have delivered measurable business outcomes for clients across various industries. Each case study highlights the strategic impact of our work, turning challenges into opportunities for growth.

Net Solutions

Ask Sol

Powered by Net Solutions

Skip the search. Start the conversation.

Ask Sol anything about digital products, AI, engineering, or growth, and get answers drawn from years of Net Solutions thinking and experience.

Our assistant helps you find content on our website. By asking a question, you acknowledge that we will process your data in accordance with our Privacy Policy, and consent to anonymous tracking of your conversation to help us improve the experience. Please avoid sharing personal or sensitive information, and close this page if you do not agree to these terms. While we strive for accuracy, AI responses may be inaccurate.By chatting you accept our Privacy Policy and anonymous analytics. Do not share sensitive information. AI answers may be inaccurate.