Skip to content
Marketplace & delivery

CrysDelivery

One codebase. Several brands. Live delivery tracking.

CrysDelivery is a white-label ordering and delivery platform built for professional provisioning. A single Flutter codebase ships as independently branded applications: name, colours, logo and Firebase backend are injected at build time, without changing a line of application code.

Category
Marketplace & delivery
Platforms
Web · iOS · Android
Context

Where it started

Shipping an ordering app for several brands normally means maintaining as many projects as there are clients. This project was built on the opposite principle: one foundation, configured from a file, with three brand configurations present in the repository. Its setup guide is written so that a new client instance can be launched without any development skills.

Two opposing requirements had to meet. For the end customer: browse a catalogue, build reusable baskets, order with a delivery slot, and watch the driver arrive live. For the operator: avoid a proliferation of codebases, since every new brand had to be deliverable without duplication or maintenance debt.

The solution

What was built

Brand identity was pulled out of the code and into an external configuration injected at build time — down to the web files (title, theme, manifest) generated from templates. The application follows strict Clean Architecture, keeping business entities separate from data models and hiding repositories behind interfaces, which isolates the logic from Firebase. Real-time behaviour relies on Firestore streams: orders, messaging and driver position update without a refresh.

Features

What the product does

  • White-label

    One codebase produces several distinctly branded applications, each with its own name, colours and backend.

  • Real-time delivery tracking

    Customers follow the driver’s position, the route and the estimated arrival time, live.

  • Hierarchical catalogue

    Categories, sub-categories and products, with instant search served from a local cache.

  • Reusable baskets

    Multiple named baskets, kept and reused from one order to the next.

  • Three-step ordering

    Locate on a map, pick a date and time slot, then review before confirming.

  • Real-time messaging

    A direct thread between customer and operator, without leaving the app.

  • Full back-office

    Manage the catalogue, orders, customers and registration requests.

  • Bilingual and secure

    French and English throughout, with biometric sign-in via fingerprint or face recognition.

Engineering

The decisions that mattered

  1. GPS tracking that doesn’t drain the battery

    Delivery tracking streams the driver’s position to the customer while computing route and estimated arrival. Broadcasting every GPS point would have drained the battery and driven up mapping call costs. Updates are therefore filtered on distance actually travelled, and route recalculation is debounced, with route-deviation detection so a new calculation only runs when it is genuinely useful.

  2. White-labelling without maintenance debt

    The real cost of white-labelling is not building the second app — it is maintaining the tenth. Brand identity was pulled entirely out of the code into a build-time configuration, down to web files generated from templates. A fix written once benefits every brand, provided no brand value is ever hardcoded — a discipline that shapes the whole project.

  3. Isolating business logic from Firebase

    Strict Clean Architecture separates business entities from data models and hides repositories behind interfaces. Errors are handled as typed values rather than thrown exceptions. The benefit is concrete: the product logic does not depend on Firebase, and stays testable and replaceable.

  4. Fast startup despite a large catalogue

    The catalogue is cached locally with version-based invalidation: the app only re-downloads data when it has actually changed. Startup is faster, search is instant, and network reads — and therefore the bill — stay contained.

Architecture

How it fits together

  1. Flutter

    One codebase for web, iOS and Android

  2. Cloud Firestore

    Real-time database: orders, messaging, driver position

  3. Cloud Functions

    What cannot run on device: emails, notifications, API keys

  4. Google Maps

    Route and estimated arrival

Tech stack

The technologies used

Frontend

  • Flutter
  • Dart
  • BLoC
  • Clean Architecture

Backend

  • Cloud Functions
  • TypeScript

Infrastructure

  • Firebase
  • Cloud Firestore

Services

  • Google Maps
  • Firebase Cloud Messaging
Result

What was delivered

Delivered on web and mobile, with three brand configurations present in the repository and an end-to-end real-time experience, from catalogue to driver tracking. Detailed figures will be added once confirmed with the client.

  • Web
  • iOS
  • Android

Need a similar product?

Let’s talk about what you want to build. I reply personally, usually within 24 hours.