Development Agency
Contact Sign in Get a project quote

Service

Marketplace platform development

For marketplace founders, retail groups and niche vertical operators who need vendor onboarding, moderated listings, split orders, commission and payouts designed around their category and their rules, rather than a general marketplace script that assumes every vendor and every product behaves the same way.

Get a project quote See the software package

The problem

What goes wrong today

Where it usually starts

A curated marketplace for a particular vertical, say independent ceramics makers or specialist outdoor gear, often starts as a shop where the founder lists other people's products by hand and settles up by bank transfer at the end of the month.

  • It grows.
  • Vendors email photographs and spreadsheets; the founder uploads them, gets a description wrong and the vendor complains.
  • A customer orders from three makers in one basket and receives three parcels on three days with one tracking number, and the complaint lands with the founder, who has to find out which maker has not shipped.

Where it gets harder

Commission is worked out in a spreadsheet from exported orders.

  • Refunds are messier still: the customer paid the marketplace, the vendor already received a payout, and nobody is sure who absorbs the loss.
  • Vendors who were carefully chosen at the start list items that do not fit the brand, and there is no moderation step to catch them.
  • A promotion planned for the season needs every vendor's agreement by email.
  • The founder is doing the work of a platform with the tools of a shop, and the better the marketplace does, the worse the month end gets.

Scope of the service

What the build covers

A custom marketplace build normally covers both sides and the platform in between. Vendor onboarding takes an application with the verification your category needs, holds it for review and opens a store page with branding, policies and delivery options once approved. Vendors manage their own products and stock within category templates you define, and new or changed listings pass through a moderation queue before they are visible. The storefront presents products across vendors with search, filters and vendor pages. A customer basket spanning several vendors is paid once through the payment adapter and split into sub-orders, each with its own fulfilment, shipping and tracking by the vendor concerned. Commission is calculated per sub-order by the rules you set, which may vary by category or vendor tier, and payout statements are produced on your schedule for payment through a provider that supports split payouts. Returns and disputes are handled per vendor, with a platform moderator able to step in and decide. Vendor performance metrics, platform-wide promotions with vendor opt-in, vendor-to-customer messaging and configurable VAT rules complete the picture.

We map your vertical first: how vendors are vetted, what a listing must contain, who ships, how commission really works, how disputes have gone and which payment provider will hold and split funds. Each becomes a named stage in the scope document.

Deliberately out of scope

  • Acting as the vendor's accountant or fulfilling on the vendor's behalf, and your own business accounting beyond commission revenue and payout statements

When the scope grows

Scoping scenario

A regional food marketplace wants producers to set their own delivery days per postcode area, a customer basket to be split so each producer sees only its items, commission to differ between fresh and ambient categories, and chilled items to be fulfilled through a single consolidated courier run the platform books. The delivery-day rules, consolidated courier run and category commission make this a custom build, and the scope document says so plainly.

Deliverables

What you receive

  • Discovery notes from walking through a vendor application, a multi-vendor order and a month-end payout
  • A written scope document naming each stage, the commission model, the moderation and dispute processes, the payment provider and what is left out
  • Designs of the vendor dashboard, the moderation queue, the storefront and split checkout and the dispute view
  • The build, including split payment, commission and payout statements where in scope, deployed to your hosting or ours
  • Migration of vendors, products, customers and order history from your current shop or spreadsheets
  • Training for your platform team and moderators, with written guides for vendors
  • Handover material and full ownership of the source code and your data

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access to your current shop, vendor list, payment and accounts tools; your vetting criteria, commission model and the payment provider under consideration.

    Project stage: Onboarding

  2. Planning

    Discovery with the founder and whoever moderates listings and handles disputes; the listing templates, split order rules, commission and dispute process are written into the scope document.

    Project stage: Planning

  3. Design

    Vendor product and order screens designed for vendors on any device; storefront and checkout designed for customers; moderation, dispute and payout views designed for your team.

    Project stage: Design

  4. Development

    Built in layers: vendors and moderation, then catalogue and storefront, then split checkout and sub-orders, then commission, disputes and payouts.

    Project stage: Development

  5. Client review

    A handful of your vendors list products and fulfil test orders with the payment provider in test mode, and your team runs a payout cycle and tells us what does not match.

    Project stage: Client review

  6. Revisions

    Changes from the review are made and re-checked against the scope document.

    Project stage: Revisions

  7. Ready for launch

    Vendors and products migrated, split payment and payouts verified against live provider accounts you control, the first payout statement checked, launch checklist signed off.

    Project stage: Ready for launch

  8. Delivered

    Orders flow across vendors; hosting and maintenance continue under their own agreement if taken.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Payment providers that support split payments and payouts to vendors
  • Parcel carriers for vendor label creation and tracking
  • Identity and business verification services for vendor onboarding, as a record of the result
  • Accounting software for commission revenue and payout reconciliation
  • Email and SMS providers for order, moderation and dispute notifications
  • Shopping channel feeds for the combined catalogue
  • Review platforms where product and vendor reviews are collected

How we would approach it

Worked example

Concept demo

A regional food marketplace with consolidated chilled delivery

In this scoping scenario, a marketplace for regional food producers wants each producer to set the days it can deliver to each postcode area, a customer basket to be split so each producer sees only its own items, commission to differ between fresh and ambient categories, and chilled items to be collected from producers and delivered in a single courier run the platform books. The scope we would propose: delivery-day calendars per vendor per zone shown at checkout, sub-orders per vendor with the platform-run courier as a fulfilment option, a consolidated collection manifest generated per run, commission rules keyed to product category, and payout statements that separate platform-delivered and vendor-delivered orders.

The custom route is needed because of the delivery-day rules, the consolidated courier run and category-based commission, which go beyond the vendor-ships-own-orders model and flat commission the package assumes.

Concept demo: a scoping scenario written to show how we would approach the work. It is not a delivered client project.

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Vendor onboarding and verification depth
  • Listing templates per category and the moderation workflow
  • Payment provider and how split payment and payouts will work with it
  • Commission model: flat, by category, by vendor tier or by volume
  • Who ships, and whether the platform consolidates any deliveries
  • Dispute and returns process and whether partial refunds are allowed
  • Volume of vendors, products and order history to migrate
  • Hosting choice: your own hosting or ours

Start from a package

Multi vendor marketplace package

Vendor onboarding and store pages, moderated vendor listings, split orders with per-vendor shipping, commission rules, payout statements, disputes and vendor messaging for marketplace operators.

Custom build
View the package

FAQ

Frequently asked questions

When is the package enough and when do we need a custom build?

If vendor onboarding with review, moderated listings, split orders fulfilled by each vendor, flat or per-category commission and a dispute queue cover your model, the multi-vendor marketplace package is the right fit and we quote for that. Platform-run deliveries, delivery-day rules per vendor, tiered commission by volume or complex verification pipelines point to the custom route.

How do vendors get paid?

Through a payment provider that supports split payments or payouts, connected during the build and named in the scope document. The platform records each sub-order, the commission and the payout statement; the funds move through the provider under its terms, not through the platform or through us.

Who handles refunds when a vendor has already been paid out?

The scope document sets the rule with you. Typically a refund decided in a dispute is deducted from the vendor's next payout, and the platform shows the vendor the deduction against the order so there is no argument at month end.

Can you move our existing vendors and products?

Yes. Vendors, products, images, customers and order history are migrated from your current shop or spreadsheets, and vendors are invited to claim their store and complete the fields the new templates need. The scope document states what can be carried over once we have seen the data.

Who owns the platform afterwards?

You do. The source code, vendor records, catalogue and orders are handed over at delivery. Hosting and maintenance are optional and agreed separately.

Get a project quote for multi-vendor marketplace software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote Discuss a partnership
Get a project quote

Cookies on this site. Strictly necessary cookies keep the site working. Allow first-party analytics so we can see which pages lead to enquiries. No advertising, no third-party trackers, no personal data; you can change this at any time on the cookies page.

Manage preferences