Lieferfair logoMarketplaces & Logistics

Rebuilding a delivery marketplace to survive its own growth

Lieferfair's order volume outgrew a platform built for a single city. We re-architected ordering, dispatch and restaurant settlement as separate services and migrated live — without a day of downtime.

3.2×
Increase in order throughput
99.95%
Checkout availability
T+1
Restaurant payouts, down from T+7
38%
Fewer support tickets
Kaidova
Book a consultation

Overview

The challenge and our approach

01The challenge

Lieferfair launched as a fair-commission alternative to the big delivery apps. The model worked — which was the problem. A monolith written for one city was now handling orders in eleven, and every Friday evening peak ended with a queue of failed checkouts and a support inbox full of missing payouts.

Settlement was the part nobody could see. Restaurant and courier payouts were reconciled by a nightly script and a spreadsheet, so a single bad batch meant a week of manual corrections and partners who stopped trusting the numbers.

02Our approach

We split the platform along the lines where it was actually breaking: ordering, dispatch and settlement became separate services with their own data, released behind a traffic switch so the old system kept serving until each piece had proven itself under a real Friday peak.

Settlement moved onto a double-entry ledger. Every order now writes the restaurant's share, the courier's fee and Lieferfair's commission at the moment it is paid, so payouts run daily and reconcile to the cent without a spreadsheet.

Courier with a thermal delivery pack on an electric scooter
Client
Lieferfair
Region
Germany
Engagement
9 months, then retained
Services
Product engineering, Cloud & DevOps, Mobile

The build

What we built

Four services and two apps, shipped one at a time behind a traffic switch.

  • Ordering service

    Stateless checkout that scales horizontally, with idempotent payment calls so a retry never charges twice.

  • Dispatch engine

    Courier assignment on live location and prep time, re-planning in under a second when a rider drops out.

  • Settlement ledger

    Double-entry records for every order, driving daily payouts to restaurants and couriers.

  • Courier app

    Flutter app with offline-first job lists, turn-by-turn hand-off and same-day earnings statements.

  • Partner dashboard

    Restaurants see orders, prep times and the payout behind each one — the numbers finance sees.

  • Peak observability

    Load tests replaying real Friday traffic, with alerts tied to failed checkouts rather than CPU.

Results

The Friday peak became a non-event

Measured over the first full quarter after the last service cut over.

  • 3.2×

    Order throughput

    Peak orders per minute the platform clears without degrading checkout.

  • T+1

    Payout cycle

    Restaurants are paid the day after service, reconciled automatically.

  • 0

    Downtime at cut-over

    Every service moved behind a traffic switch while the old system kept running.

  • 38%

    Fewer tickets

    Most of the support queue had been payout questions that no longer come in.

Tech stack

What it runs on

  • Apps

    • React
    • Next.js
    • TypeScript
    • Flutter

  • Services

    • Node.js
    • PostgreSQL
    • Redis

  • Infrastructure

    • AWS
    • Docker
    • Kubernetes
    • GitHub

From start to finish, an excellent and effective build. Our delivery platform went live smoothly and we will be working with the Kaidova team again very soon. Look no further.

Hira JavedCEO, LieferfairLieferfair logo

More case studies

Other work we are proud of

All case studies

Facing a problem like this one?

Thirty minutes with a solution architect — walked through your own system, with an honest answer on whether we are the right team for it.

Book a free call