Platformă retail europeană: stack multi-tenant Flutter pentru 6+ retaileri tier-1

The client

A leading European retail-technology vendor whose Multi-Device Combo (MDC) platform powers in-store self-scan, store-attendant, and terminal-management workflows for some of the largest grocery chains on the continent. The brands include household names across Germany, the Netherlands, the United Kingdom, and beyond.

This is a real-world, hardware-bound, mission-critical retail stack. When the cashier at the Sunday-evening rush at a flagship store can't authorize a void, that's the bug — and the team has minutes, not days.

The challenge

Tier-1 retailers do not want generic software. They want their brand, their workflows, their regulations, their hardware — and they want it on launch day. Building one app per retailer is a death march. Building one generic app and forcing every retailer to live with it is a sales-killer. The only sustainable answer is a platform: a shared core with brand-specific surfaces and pluggable hardware drivers.

On top of that, the in-store hardware is a zoo: Zebra handhelds, Cognex barcode engines, Datalogic scanners, Honeywell terminals, Digimarc digital watermarking, ML Kit for fallback on commodity Android. Each vendor has its own SDK, its own quirks, its own firmware quirks. The platform has to abstract them without losing the per-vendor performance the stores depend on.

What we built

We work inside an open, public engineering ecosystem at github.com/extenda — specifically the mdc-flutter and mdc-attendant repositories.

A layered Flutter platform

plugins/  → native scanner drivers (Zebra, Cognex, Datalogic, Honeywell, Digimarc, ML Kit, terminal manager)
packages/ → device abstractions (mdc_zebra_device, mdc_cognex_device, mdc_scanner_engine, mdc_mqtt_client, ...)
modules/  → product features (mdc_selfscan_ui, mdc_onboarding, mdc_trip, mdc_dynamic_screensaver, ...)
uis/      → brand-specific apps (mdc_kaufland, mdc_rewe, mdc_penny, mdc_waitrose, mdc_hoogvliet, mdc_globus_sbw, mdc_attendant)

Same core. Same scanner abstraction. Each retailer gets a uis/<brand> flavor that composes the modules, themes the experience, and ships as a separate app — with its own bundle ID, store presence, and rollout schedule.

Hardware drivers as Flutter plugins

Every scanner vendor lives behind the same mdc_scanner_engine interface. Switching from a Zebra to a Honeywell terminal means swapping the plugin and the device package — the UI and the business logic don't move. New hardware models are added by writing one plugin, not by forking the app.

A real-time fabric over MQTT

Stores need real-time signals: device state, terminal-manager events, in-flight transactions, screensaver triggers. We use MQTT as the lightweight backbone, with mdc_mqtt_client and mdc_socket_io providing the abstractions, so the UI reacts to backend changes without polling.

A separate-but-aligned attendant app

The mdc-attendant repository hosts the cross-platform store-attendant experience — the app that staff use to assist self-scan customers, override prices, manage scanner-wall views, and handle exception flows. It shares the same mdc_zebra_device, mdc_mqtt_client, mdc_selfscan and mdc_catalog packages as the main self-scan platform. One ecosystem, two product surfaces.

Engineering practices

• Pure plugin/package isolation — Cognex, Datalogic, Honeywell, Zebra, Digimarc and ML Kit drivers each live in their own plugin so retailers can deploy with whichever hardware they procured
• Per-brand build targets — every retailer has its own uis/<brand> flavor; CI builds them independently
• Deep native integration — Kotlin code in the plugins talks directly to vendor SDKs; Dart only sees a clean abstraction
• Production-grade observability — mdc_native_logger, structured device-info reporting, and lifecycle hooks so support teams can triage from logs without leaving the office

Outcomes

• One Dart/Flutter codebase, six+ branded retailers in production across multiple European countries
• Hardware-vendor swappability — onboarding a new scanner model is a plugin task, not a fork
• A cross-platform attendant app sharing the same core packages
• A platform that has scaled both vertically (more retailers) and horizontally (more hardware vendors) without rewriting the core

If your business runs on hardware in stores, you need a platform — not an app. This is what one looks like done right.