Marketplace Middleware Case Study: DASH Rides
The operational layer behind a UK Cycle to Work marketplace, where 61,000 products from 42 suppliers resolve into 28,000 live listings.
This case study covers the internal platform behind DASH Rides, a UK Cycle to Work marketplace where employees buy bikes through their employer and repay through payroll deduction. Binary Future has worked on the project since 2023 and owns the admin platform and middleware: supplier onboarding, product import and review, pricing, orders, purchasing, payments and data exchange with external systems.
The project was built using Python and Django, with integrations including Shopify API, OpenAI API, Xero API, and Firecrawl API.
The system connected 42 suppliers and processed 61,000 products, with 28,000 live listings and more than 300 orders placed in the last month.
The project was delivered by a team that included a senior full-stack developer, two Python developers, a frontend developer focused on specific interface work, one to two QA engineers, and a project manager.
61K source products from 42 suppliers resolved into 28K live listings
DASH Rides is a London-based marketplace for electric and sports bicycles. Its customers are employees of partner companies who purchase bikes through the Cycle to Work scheme, with the cost repaid through regular payroll deductions.
The storefront is handled by a separate partner team. Behind it sits the platform built and managed by Binary Future, covering supplier management, catalog administration, integrations with supplier stores, product review and publication, pricing, orders, purchasing, payments, and returns.
The platform connects three separate worlds: DASH’s marketplace, its suppliers, and a range of third-party systems. Rather than relying on an off-the-shelf solution, the entire backend was built from scratch.
Binary Future designed the application architecture, database structure, business logic, and integration layer that keep these systems connected and allow DASH staff to manage the marketplace from a single admin platform.
DASH Rides
Cycle to Work marketplace, electric and sports bicycles
London, United Kingdom
Custom Django platform with Shopify integration
Interface design comes from the client, who works with Figma himself. Binary Future handles technical analysis, implementation, testing and integration of his requirements.
They manage suppliers, review and publish products, control pricing, and process orders and payments.
They connect their store, import products and see only their own catalog inside the system.
Their products arrive through feeds, scraping or manual entry, and the store owners never touch the platform.
One product, several sources, different names
The same bike arrives from different suppliers under different brand names, categories, colors and attribute labels. The marketplace needs one listing, not five.
Five ways suppliers connect
Shopify, Custom Webfeed, Google Shopping, Firecrawl scraping and manual entry. There is no single protocol, and a single supplier file can carry anywhere from 200 to 50,000 products.
The storefront price is not the supplier price
Commissions depend on category, subcategory and the individual supplier, and all of it has to resolve down to the product variant.
One customer order is several purchases
The buyer completes one transaction, behind which sit products from several suppliers, each with its own purchase, payment, delivery and possible return.
The purchase is tied to payroll
Behind every item sits an agreement whose deduction schedule lives in an external system, and the platform has to stay in step with it.
Order status cannot be set by hand
Too many participants and too many transitions to rely on someone remembering to flip a flag.
Django for the backend
Chosen for the complexity of the business logic, the number of interrelated entities and the scaling ahead. The platform was designed as a system with a heavy domain model rather than a set of sync scripts.
An app inside Shopify rather than file exports
For Shopify suppliers the team built a dedicated app that installs in the store and acts as the link. Through it the system receives products, variants, prices, stock and changes, while webhooks keep everything current without scheduled polling.
Different channels for different suppliers rather than one universal one
Full platform access is required only from Shopify vendors. Feeds, Google Shopping and scraped sources run automatically, which removes the need to persuade every supplier to install something. Suppliers now include brands such as Brompton, Decathlon, Ribble, Canyon and Volt Bikes.
Supplier onboarding
An administrator creates the supplier account with store details, owner, logo and the commission settings applied to their sales. The supplier receives credentials, accepts the mandatory policies at first login, then installs the DASH app in their store and authorizes data exchange.
Product import and a two-stage review
The supplier syncs products on their side, after which a DASH administrator runs their own review and selects what to publish. Only after publication does a product reach Live status. Administrators see the catalog across all suppliers, suppliers see only their own.
Webhooks on store changes
The product module tracks changes in supplier stores and keeps availability, stock, prices, variants and product page edits current.
Pricing module
The storefront price is calculated separately from the supplier price. Rules are set globally, commissions are assigned by category and subcategory, and settings can differ for an individual supplier within the same category. The final price is calculated per variant.
Five supplier channels
Shopify, Custom Webfeed, Google Shopping, Firecrawl API scraping and manual creation inside the system. The account is created the same way in every case, then connection proceeds by URL depending on the channel.
Two modes per data source
Commerce, where the system pulls full commercial information including stock, variants and statuses, or enrichment, where the source only supplies descriptions and details to enrich existing listings.
Orders 2.0 module
A single workspace covering purchase confirmation, placing the order with the supplier, delivery, payment, invoicing, return and cancellation. Two interfaces: Orders Hub with orders listed by status, and Orders Console as the detailed working area for a specific order. It supports every supplier type, including those whose purchases are placed manually.
Three-level order structure
A customer order splits into consignments by supplier, and each consignment into individual items. Purchasing, payment, delivery and returns are tracked per item, even though the buyer saw a single transaction.
Status derived from event history
Rather than assigning status by hand, the system stores the sequence of events per item and derives the current state from it. An employer approving or rejecting a purchase is recorded as an event, not as a checkbox.
Ledger controls without ledger logic
The payroll deduction schedule is calculated by an external system. The platform holds a state flag per item and gives staff the controls to pause, restart or permanently stop deductions, while the external schedule itself is surfaced in the interface. The item enters the ledger when the order is created and approved.
Golden product: one listing out of five different source records.
Once there was more than one source, the same bike started arriving from different stores under different names. In one place it is “bike in black”, in another simply “bike”, the color is a shade, each supplier has its own category, and the brand is spelled its own way.
The team built a module on OpenAI that brings incoming data to a common shape: it recognizes and matches brands, assigns categories and normalizes attribute names. Titles are unified, color mentions are stripped out of them, and the color itself is resolved separately: the color code goes to the model, the answer returns to the system, and the system maps it onto an existing color in its own reference table.
On top of that sits the golden product, the single listing that appears on the marketplace. Records merge into it through a ranking system that prioritizes title match first, then brand, then category.
A golden product can hold several variants from several suppliers, and related products always show where each variant came from.
Every merge carries a confidence score. In testing, 60,000 source products produced roughly 26,000 golden listings, of which around 20,000 were clean enough to go live unreviewed and 6,000 were flagged for administrator review. Automatic publication is currently switched off at the client’s request, so every merge passes through review.
The module was built by three backend developers and a QA engineer who maintained the test documentation and ran functional and regression testing. Development took three to four months, with several iterations before the processing rules settled.
61,000 source products resolved into 28,000 live listings
Duplicate records from different suppliers collapse into single listings rather than competing on the storefront.
42 suppliers across five channel types
15 connect through webfeeds, the rest through Shopify, alongside Google Shopping, scraping and manual entry. A single supplier file ranges from 200 to 50,000 products.
300+ orders in the last month
appearing in the system immediately on purchase.
Multi-supplier orders became manageable
The three-level structure allows purchasing, payment, delivery and returns to be handled per item.
Manual statuses gave way to event history
Current state is derived from the sequence of events rather than from whoever remembered to switch it.
The marketplace can grow without proportional growth in administration
Adding suppliers and handling more orders no longer depends on how many people process things by hand.
Orders 2.0. The module is in active development, replacing scattered manual processes with a transparent, partly automated workflow.
Xero integration. The client runs accounting in Xero, and Orders 2.0 automates the transfer of purchasing documents there. When an order is paid or an invoice uploaded, DASH creates an accounting record with supplier details, date and order number. Xero returns a unique identifier that is stored and used to attach the related PDF invoices.
A marketplace whose suppliers connect in different ways, with no single exchange protocol
A catalog where the same product arrives from several sources under different names
A business with complex pricing, where the storefront price is calculated by rules rather than taken from the supplier
An order that looks like one transaction to the buyer but splits internally into several purchases
A company that needs a managed layer between storefront, suppliers and accounting rather than a pile of exports