Industries · Marketplaces and on-demand

Two sided marketplaces where both sides get a product worth opening.

Technicians booked and dispatched from a phone, providers with calendars and saved card payments, restaurant owners matched to verified trades, and lunch ordered, paid and ridden to a school door.
Five marketplaces are written up here. Each has a customer side, a provider side and an admin that sees the whole thing.
Case studies
4 projects written up: JOBIQ, LYNXNET, GLOSS & HAMMER, TEACHERS LUNCH.
Built for
On-demand service startups, home services companies, food delivery operators and B2B service networks.
Typical scope
Customer app, provider app or portal, admin console, one API with bookings, chat, payments and disputes.
Rated
4.7 / 5 from 23 Google reviews

In short

A marketplace is three products that have to agree with each other: the customer's app, the provider's app or portal, and the admin that sees the whole thing. JobIQ, Skills Sync, Lynxnet, Gloss & Hammer and Teachers Lunch each run that shape on one API, with bookings, chat, payments, verification and disputes handled in the product rather than by email.

What the sector asks of software

Three things every marketplace build has to get right.

Each one is drawn from a project on this site, not from a sector report.
01

Three products that have to agree with each other

JobIQ is a customer app, a vendor portal and an admin console on one API. A job booked on a phone appears on the vendor's board and in the admin's numbers at the same moment.

JobIQ

02

Trust is the product

Gloss & Hammer verifies providers before they are listed. Lynxnet carries reputation as badges and gives both sides a dispute form in the app with a dispute desk behind it. Skills Sync lets providers earn badges, tiers and rewards from real bookings.

Gloss & Hammer, Lynxnet, Skills Sync

03

Payment has to be boring

Skills Sync books into a provider's calendar and pays with a saved card. Teachers Lunch takes cards with webhook confirmation and sends SMS and push updates while a rider's map moves.

Skills Sync, Teachers Lunch

Case studies · Marketplaces and on-demand services

4 projects behind this page, each from the problem it began with.

Open any card for the brief, what we did and what changed for the people using it.

All case studies
01

Home services

JOBIQ

A marketplace where customers book a technician, vendors run their teams, and the platform handles chat, dispatch and payment.

JobIQ is three products that have to agree with each other: a customer app, a vendor portal and an admin console. Bookings, technicians, catalogue, chat and reporting all live in one API, so a job booked on a phone appears on the vendor's board and in the admin's numbers at the same moment.

View case
02

Marketplace

LYNXNET

Providers list services and bookings; customers post requests, book, bookmark and chat; disputes and transactions are handled in an admin.

LynxNet is a two sided marketplace. Providers create and edit services and take bookings, customers send out requests, book a service, bookmark providers and chat, and reputation is carried as badges. When something goes wrong there is a dispute form in the app and a dispute desk, transactions and documents in the admin.

View case
03

Marketplace

GLOSS & HAMMER

A two-sided marketplace where restaurant owners post jobs and verified trades, cleaners and maintenance firms pick them up, with separate journeys for owners and providers and a dashboard for both.

Gloss & Hammer sits between restaurants that need something fixed, cleaned or installed and the providers who do it. Owners post a job and see verified providers respond; providers build a profile, get verified and pick up work. The site had to sell both sides without confusing either.

View case
04

Food delivery

TEACHERS LUNCH

A food ordering platform with a customer app, a rider app, restaurant menus, payments and an admin that sees the whole day.

Teachers Lunch connects restaurants to staff who cannot leave the building at lunchtime. Orders flow from a menu to a cart to a rider's map, with payment, chat and notifications handled in the same API, and an admin panel with analytics for the operator.

View case

Sector notes

What building marketplaces has taught us.

Five two sided products across home services, skills, trades and food delivery. These are the things we would say to a marketplace founder before the first sprint.

01

One API, three surfaces, no lag between them

JobIQ is a customer app in Flutter, a vendor portal in Next.js and an admin console, all on a NestJS and MongoDB API. Bookings, technicians, the catalogue, chat and reporting live in one place, so a job booked on a phone appears on the vendor's board and in the admin's numbers at the same moment. Per job, the customer and the vendor see the same chat, map and status.

Vendors manage their own plans and reporting from the console, which is the difference between a marketplace that scales and one that runs on the founder's inbox. Teachers Lunch follows the same shape with two Flutter apps, customers and riders, restaurant and admin web, and a NestJS API with Stripe, Twilio SMS and push.

02

Trust is built into the product, not promised in the copy

Gloss & Hammer sits between restaurants that need something fixed, cleaned or installed and the providers who do it. Providers are verified before they are listed, owners post a job and see verified providers respond, and both sides share one dashboard. The landing page had to sell two journeys without confusing either.

Lynxnet carries reputation as badges on profiles and gives both sides a dispute form inside the app with a dispute desk in the admin, so when something goes wrong there is a process rather than an argument. Skills Sync lets providers earn badges, tiers, achievements and rewards from real bookings. In every case the trust signal is produced by the system from actual behaviour.

03

Payment has to be boring

Skills Sync books a customer into a provider's availability calendar and takes payment with a saved card through Stripe setup intents, so a repeat booking never asks for the card again. Teachers Lunch confirms card payments by webhook and sends SMS and push updates while the rider's map moves. Nothing in the product trusts the client's word that money changed hands; the provider's webhook is the record.

Disputes, refunds and payouts are designed with the same seriousness as checkout. A marketplace that gets payment right earns the second booking, and the second booking is the business.

04

The admin is a product too

Every marketplace here has a Next.js admin that the operator actually uses: Lynxnet's dispute desk, JobIQ's reporting, Teachers Lunch's analytics and broadcasts, Skills Sync's marketplace management. Reports, bans, categories and payouts are handled there rather than in a database console.

We scope the admin from the first sprint because it is where the founder spends their day once the apps are live. A marketplace with a thin admin is a marketplace that will need a rebuild at the first thousand users.

What we build

From the first booking to the dispute desk.

Each capability below has shipped inside at least one of the five marketplaces on this site.
Explain your project
  • Customer apps

    Browse, book, pay, chat and track, with status visible per job.

    Customers book, pay and track in one place and come back for the second booking.

  • Provider apps and portals

    Services, availability calendars, teams, plans and reporting the provider manages themselves.

    Providers run their own services, teams and plans without your inbox.

  • Dispatch, chat and maps

    Per job chat, live location and status shared by customer and provider.

    Both sides see the same job, status and location at the same moment.

  • Payments and payouts

    Stripe setup intents, saved cards, webhook confirmation and self-serve plans.

    Money is confirmed by the provider and never trusted from the client.

  • Verification, badges and disputes

    Providers verified before listing, reputation earned from bookings, disputes raised in app and resolved in the admin.

    Trust comes from the system, and problems have a process.

  • Delivery and rider apps

    A rider app with the order on a map, and an operator admin with analytics and broadcasts.

    Riders follow the order on a map while the operator watches the numbers.

How it ships

How a marketplace ships with us.

The path JobIQ, Skills Sync, Lynxnet, Gloss & Hammer and Teachers Lunch took, from the loop on a whiteboard to the second booking.

Your briefMarketplace or on-demand founder

Discovery

  • Design the loopCustomer, provider, adminAll three scoped together so release one has a working loop.
  • Trust and money rulesVerification, badges, disputes, payoutsDecided before a screen, built into the API.

Build

  • One APINestJS or Node, MongoDB, socketsBookings, chat, maps, status and reporting in one place.
  • Customer and provider appsFlutter, Next.js portalsPer job chat and status visible to both sides at once.
  • Payments and disputesStripe setup intents, webhooks, dispute deskSaved cards, confirmed payments, a process when things go wrong.
Delegated to
Flutter engineerAPI engineerNext.js engineerPayments engineerQA lead

Quality

  • Providers firstOnboarded and verifiedThe first customer booking finds someone to take it.
  • Admin walk throughReports, bans, payouts, analyticsThe operator runs a day on the admin before launch.
  1. ApprovedClient sign off per release
  2. ObserveTwo weeks of live use
  3. Live and handed overCode, cloud and docs are yours

Numbers from the work

What the marketplace projects delivered.

Taken from the case studies, not rounded up.

3

JobIQ products on one API: customer app, vendor portal, admin

Saved cards

pay in Skills Sync and rebook without re-entering

Verified

Gloss & Hammer providers before they are listed

2

Teachers Lunch apps, customers and riders, on one backend

Questions marketplace founders ask us

It depends on how many surfaces.

A customer app, a provider side and an admin on one API is the usual shape. We scope the three together so the first release has a working loop rather than one polished half.

Tell us what the business needs. We will tell you what to build first.

Schedule a free consultation and get a written recommendation, with costs, before you commit to anything.

Get in touch

PROVEN RESULTS

4.7 / 5from 23 Google reviews