#R08 — Client Applications & Device Fleet Management

Scope: every screen the product ships, the framework decision for each, app distribution, MDM/fleet ops, and the POS-specific UX constraints that engineers routinely underestimate. Date: 2026-08-18. Labels: [verified] = checked this session with a URL, [known] = confident from training data, [estimate] = reasoned guess. Reads alongside: r01-hardware-peripherals.md (printers, terminals, GMS/EDLA trap), r04-offline-sync-domain.md (sync core, hub election), r03-fiscal-regulatory.md, r06-crm-loyalty-privacy.md. Effort here excludes the sync core, the printing stack, fiscal drivers, payments certification, and backend — those are costed in their own docs.

#0. Bottom line up front

1. You will ship 11–14 distinct client surfaces. That is the real scope of "a POS + CRM", and it is why this category eats EUR 5M. Ranked honestly, only three are required for a first paying customer: the POS terminal app, the back-office web console, and a kitchen output path (printer is enough; KDS is a fast-follow).
2. Framework verdict: Kotlin + Jetpack Compose, Android-first, structured as Compose Multiplatform modules from day one. Web (React/TypeScript) for back office, guest ordering, and QR. No Flutter, no React Native, no dual-native, no Electron. The decisive argument is not rendering performance — it is that every peripheral and payment SDK in the certified matrix is a Java/Kotlin AAR, and bridging 10–14 of them into a JS or Dart runtime costs 4–7 engineer-months of pure glue plus permanent maintenance. Kotlin makes that cost zero. Section 2.3 has the arithmetic.
3. The switch condition is explicit: if the beachhead flips to Western EU or the US, iPad share rises materially and Compose-Multiplatform-on-iOS becomes a load-bearing bet rather than a free option. In that world React Native (New Architecture) is the safer pick. Decide the beachhead before you write the first Gradle file.
4. Two operational facts will hurt more than any framework choice:
   • Android cannot downgrade an app in place. Uninstall/reinstall wipes app-private storage — i.e. the offline order journal. Therefore rollback does not exist; you have forward-fix + staged rollout + server-side kill switches, or you have Friday-night outages.
   • Silent app install on Android requires Device Owner mode, which can only be established at factory-reset time. A device an installer unboxed and set up "normally" can never be silently updated again without wiping it. This makes the 20-minute install runbook a product requirement, not ops hygiene.
5. Apple's App Review is not the P1 risk people think — 90% of submissions clear in under 24h and expedited review is typically ~24h [verified]. The real Apple risks are: no rollback, Guideline 4.2.6 (no per-restaurant white-label apps for SMB), the multicast entitlement, and the Local Network permission prompt that silently kills printer discovery on install day.
6. Budget EUR 12–30/site/month for MDM at 6 devices/site. Against a EUR 79–129/site/month subscription that is 10–25% of gross margin. Recommendation: cheap MDM for enrolment + kiosk lock + OS update windows only (Mosyle EUR ~1/device, Hexnode EUR ~1–1.8) and put diagnostics/telemetry/remote-config inside your own app, where it works offline and you control it. Esper (USD 2–6/device, 25-device min [verified]) is worth its premium only once you have >200 sites or a self-order kiosk fleet.

#1. Surface inventory and MVP ranking

#1.1 The full list

Two surfaces are missing from the brief's list and belong in it: #13 fleet agent and #14 internal support console. Teams skip them and then discover that customer #30 costs the same engineering attention as customer #1.

#1.2 MVP ranking (build order)

Explicit non-goals for v1: drive-thru; native per-restaurant white-label guest apps (see §4.6); a Windows/desktop POS client; a smartwatch app; anything on a TV OS.

#2. Framework decision — hard verdict

#2.1 The five tests, stated as falsifiable requirements

#2.2 Candidate matrix

#2.3 The decisive argument: the SDK bridging tax

Enumerate the native SDKs the counter app must call in the first 24 months:

Plus a permanent tax: every vendor SDK bump re-tests the bridge, every RN/Flutter major bump re-tests all of them. Budget 0.15–0.25 eng-months/quarter forever [estimate].

In Kotlin this number is zero. Five and a half engineer-months is ~14% of the entire client-app budget in §Build effort, and it buys nothing a customer can see. That is the verdict.

The honest counter-argument: RN would let you share TypeScript domain logic with the back office and guest PWA. But per r04 the authoritative domain is an event-sourced core that should live in one place and be deterministic — and KMP compiles that same Kotlin core to a JVM backend and to JS/Wasm for the web console if you want it. Kotlin gives you the shared-core benefit too, in the direction that matters.

#2.4 Verdict, stated as a commitment

Counter surfaces (POS, handheld, KDS, expo, CFD, kiosk):
    Kotlin 2.x + Jetpack Compose, min SDK 26 (Android 8.0), target latest
    Module layout from day 1:
        :domain      (KMP, pure Kotlin, no Android deps)  <- shared with backend
        :data        (KMP, SQLDelight, sync client)
        :ui-core     (Compose Multiplatform: design system, POS widgets)
        :ui-pos / :ui-kds / :ui-cfd / :ui-kiosk   (CMP where possible)
        :android-app (Android-only: AIDL, USB, DPM, vendor SDKs)
        :ios-app     (NOT built in v1; the seam exists)

Back office, guest ordering, QR PWA, internal support console:
    TypeScript + React (Vite), no SSR-heavy framework for the console;
    guest ordering gets SSR (Next.js or Remix) for SEO + first-paint

Optional site bridge (Windows/Linux, only if fiscal or legacy serial forces it):
    Tauri 2.x + Rust, ~30 MB, no Chromium bundle

Languages the company maintains: Kotlin + TypeScript (+ Rust only if the bridge ships).

What would flip this to React Native: (1) beachhead becomes US or Western EU with >40% iPad attach; (2) you decide to sell a per-restaurant branded native guest app (you shouldn't — §4.6); (3) you cannot hire 2 senior Android engineers in 8 weeks.

What would flip this to Flutter: essentially nothing, unless your existing team is already a Flutter team — in which case use Flutter and eat the 5.5-month bridging tax, because team familiarity is worth more than 5.5 months.

#2.5 What iPadOS forbids (the concrete list)

#2.6 What Android POS vendors require

#3. Distribution

#3.1 Channel matrix

#3.2 The Friday-night P1, with a clock

Scenario: 19:40 on a Friday, a build shipped Thursday turns out to drop every third kitchen ticket at sites with two printers. 180 sites, mid-service.

Rules that follow, non-negotiable:

1. Every risky code path ships behind a remotely-flippable flag with a locally-cached default, and the flag store must work when the site's WAN is down (last-known-good config persisted, TTL 7 days).
2. Release freeze Thursday 12:00 → Monday 10:00. No exceptions, including "it's just a copy change".
3. Staged rollout cohorts: internal lab (1) → 3 friendly sites → 10% → 40% → 100%, with a minimum 24 h soak spanning at least one dinner service at each step. Never advance on Fri/Sat.
4. Forced-update policy must degrade, not block. A server returning 426 Upgrade Required that hard-blocks the till at 20:00 is an outage you caused. Correct behaviour: client below min_supported enters grace mode — local-only order entry and printing continue, sync is paused, a non-modal banner appears, and hard-block only triggers after min_supported_hard (set weeks later) and only outside the site's configured service hours.
5. Version skew is permanent. A device offline for 3 weeks (r04 §4.6) will rejoin on an old client. The sync protocol must be N-2 compatible in both directions, with a schema version negotiated per connection.

#3.3 The Android rollback trap, spelled out

• Android refuses in-place downgrades of a signed app (INSTALL_FAILED_VERSION_DOWNGRADE).
• PackageInstaller rollback (SessionParams.setEnableRollback) requires system/privileged context — not available to a normal Device Owner app for arbitrary APKs [known — verify against current AOSP for your target API level].
• Uninstall/reinstall wipes /data/data/<pkg> — the SQLite journal of unsynced orders.

Mitigations, in order of value:

1. Feature flags + kill switches (as above). This is 90% of the answer.
2. Store the event journal where a reinstall cannot destroy it: a second copy in app-scoped external storage or a BackupAgent-eligible location, encrypted with a Keystore-held key that is escrowed server-side per device. Costs ~0.4 eng-months and turns a catastrophe into an inconvenience.
3. Keep the previous APK cached on-device so a reinstall is offline-capable.
4. Ship a recovery build channel: a tiny, rarely-changed app that can (a) export the local journal to a file, (b) fetch and install a specified version, (c) display support contact and a device ID. Installed at provisioning, updated twice a year.

#4. Fleet management

#4.1 MDM options and real prices

#4.2 Recommendation and the cost math

A reference single site runs 6 devices: 1 till AIO, 1 KDS, 1 handheld, 1 CFD (often the till's second screen — count it as 0), 1 spare/manager tablet, 1 kiosk (only in QSR). Realistically 4–6 managed endpoints.

The split that works: MDM owns what only the OS can do — enrolment, supervision, lock-task/kiosk, OS update windows, network/Wi-Fi payloads, remote wipe, lost mode. Your own in-app agent owns everything else — app version, remote config, feature flags, log capture, printer health, telemetry, "send diagnostics", remote restart of the app, sync status. Your agent works offline against a cached config; an MDM does not. Your agent knows what a "printer" and an "unsynced order" are; an MDM does not.

#4.3 Zero-touch provisioning: 6 devices in under 25 minutes

Target: a non-technical installer (or the restaurant owner, from a box shipped by courier) brings a site live without a phone call.

Android (the primary path):

1. Devices are shipped pre-registered. Either (a) the reseller enrols them in the Android zero-touch portal (GMS/EDLA SKUs only), or (b) we ship a printed QR provisioning card in the box. The QR encodes:

   {
     "android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME": "com.rb.dpc/.AdminReceiver",
     "android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM": "<base64url SHA-256 of signing cert>",
     "android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "https://ota.rb.example/dpc-<ver>.apk",
     "android.app.extra.PROVISIONING_WIFI_SSID": "<site ssid>",
     "android.app.extra.PROVISIONING_WIFI_PASSWORD": "<key>",
     "android.app.extra.PROVISIONING_SKIP_ENCRYPTION": false,
     "android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": { "site_claim": "K7M-4T2", "role": "TILL" }
   }

   [known — key names are stable across API 26+; verify checksum encoding]
2. Installer powers on, taps the welcome screen 6× → QR scanner opens → scans the card. Device joins Wi-Fi, downloads the DPC, becomes Device Owner. ~4 min/device, mostly download.
3. DPC applies policy (lock task, disable factory reset, disable USB debugging, setSystemUpdatePolicy window 03:00–05:00) and silently installs our app.
4. Our app launches, reads site_claim from the admin extras, calls home, and self-assigns its role (TILL / KDS / HANDHELD / CFD / KIOSK) from the pre-built site plan in the back office.
5. Printer discovery wizard runs (r01 §2.6): mDNS + Epson UDP 3289 + ARP sweep → installer confirms which physical printer is "KITCHEN" via a test print that prints the station name in 48 pt → assign static IP + record MAC → print and stick a physical label.
6. Menu + staff + tax config sync down. Site is live.

Timing [estimate]: 4 min/device × 6 = 24 min of device time, ~8 min of which is parallelizable; printer wizard 6–10 min; total 25–35 min for a competent installer, 60–90 min for a first-timer following a printed runbook. Budget 1.0 eng-month for the wizard + runbook (also counted in r01 item 12).

Apple (if/when iPads exist) — the purchasing constraint that surprises people:

• Automated Device Enrollment requires the device to be in your Apple Business Manager org, which requires purchase from Apple or an Apple Authorized Reseller who links the order to your ABM Organization ID. [known]
• A device bought from a random EU webshop is not in ABM. Your only fallback is Apple Configurator over USB on a Mac — ~2 min/device and it grants the user a 30-day provisional window in which they can un-enrol. [known]
• Therefore: iPad procurement is an ABM-linked purchasing decision, not a shopping decision. Write it into the reseller agreement or you will be manually configuring iPads forever.

#4.4 Remote diagnostics and screenshare

Design consequence: because iOS remote control does not exist and Android remote control costs Esper money, the product must be self-diagnosing. Ship a Device Health screen on every device — printers with green/amber/red, last sync time, unsynced count, WAN/LAN status, app version, storage free, battery/thermal — plus a single "Send diagnostics to support" button that bundles logs + config + last 50 orders' metadata and returns a 6-character reference the staff member reads over the phone. This one screen removes an estimated 30–40% of support call time [estimate].

#4.5 Telemetry, offline recovery, lost/stolen

Telemetry event set (v1, deliberately small):

Volume: 6 devices × 1,440 heartbeats/day × ~200 B ≈ 1.7 MB/site/day → ~50 MB/site/month. At 1,000 sites that is 50 GB/month ingested — trivial cost, but compress and batch on the device, because r01 §4.4 notes CEE sites often run on LTE backup during outages where every megabyte is metered.

Offline recovery — the "site is dark for 3 days" plan:

• The app must boot, open a table, take an order, print, take cash, and print a Z report with zero network. This is the r04 requirement restated as a client requirement.
• Config, menu, tax rates, staff PINs, and feature flags are all persisted with a last-known-good copy and a 7–30 day TTL that warns rather than fails.
• Ship a physical recovery card in the install kit: support phone number, site ID, device IDs, and an offline manager override code (HMAC of site_id + date, verifiable offline) so a manager can void/refund without a server.
• The recovery build channel (§3.3) is the last resort.

Lost / stolen:

• Handhelds are the realistic loss vector, not 15" AIOs.
• Controls: PIN-on-wake after 60 s idle; full-disk encryption (default on modern Android/iOS); device-bound key in Keystore/Secure Enclave so a cloned APK on another device cannot sync; server-side device certificate revocation that takes effect on next connect; MDM lost-mode/lock/wipe.
• Because we hold no card data (r01 PCI posture — payment lives on the terminal), a stolen handheld is a hardware loss (EUR 400–600) plus a GDPR question about the guest data cached on it. Cap the on-device guest cache: today's orders + loyalty balances for guests seen today, nothing historical. This is also the r06 §6.6 DSAR answer.

#4.6 The white-label trap

Do not ship a per-restaurant branded native app for SMB. Apple Guideline 4.2.6 rejects apps produced from a template/generation service unless submitted by the client from their own account [known], Google is increasingly similar in practice, and 500 App Store listings is 500 review queues, 500 sets of screenshots, and 500 places a P1 can hide. Correct shape: one multi-tenant guest PWA under the restaurant's own domain (order.restaurantname.pl, white-labellable in CSS and logo), plus Apple/Google Wallet passes for loyalty (which are per-brand and cost nothing to mint). Reserve native guest apps for chains with 5+ sites who will fund their own developer account.

#5. POS UX constraints engineers underestimate

#5.1 Latency budget (the one that decides whether staff like you)

The classic killer: a 4000 px menu photo decoded at scroll time costs 60–120 ms of main-thread work and produces a visible stall exactly when the queue is longest. Pre-resize every menu image server-side to the exact device pixel sizes you ship (e.g. 240 px and 480 px squares) and cache them on disk at provisioning. Ship p99 frame time as telemetry so this regresses loudly, not quietly.

#5.2 The physical environment

#5.3 Train in 15 minutes

Make this a testable acceptance criterion, not an aspiration. A new hire who has never seen the product must, with a 90-second video and no trainer, complete in ≤ 15 minutes:

1. Clock in with a 4-digit PIN.
2. Open table 12, add 3 items including one with a required modifier group.
3. Fire course 2.
4. Split the bill 2 ways by item.
5. Take a card payment and a cash payment with change.
6. Void an item (with a manager PIN override).
7. Clock out.

Run this test with actual restaurant staff, not engineers, at least once per quarter. Anything that fails it moves to the manager-only surface or the back office. Role-based UI is the mechanism: a server sees perhaps 20% of the app's functionality; a shift manager 60%; the owner uses the web console, not the till.

Why it matters commercially: hospitality staff turnover in the EU runs high (commonly cited at 70–100%/yr in the sector [estimate]), so training cost is a recurring cost the operator pays, and "the new kids can't work the till" is a genuine churn driver.

#5.4 Multi-language staff

• Language is a property of the user, not the device. In PL/CZ/DE the kitchen brigade frequently works in Ukrainian or Russian, the servers in the local language, the owner in a third (r01 §2.7).
• v1 language set for the CEE beachhead: uk, ru, pl, cs, ro, en, de, sk — 8 locales. Add es/it/fr/pt/nl for Western EU (13 total).
• Sizing: ~1,400–1,800 UI strings at v1 [estimate]; professional translation EUR 0.08–0.15/word; average 3 words/string → EUR 3,000–6,500 initial, EUR 400–900/month upkeep [estimate]. Machine translation with a native reviewer per locale halves this and is acceptable for a POS but not for guest-facing legal/consent copy (r06 §6).
• Engineering rules: no string concatenation; ICU MessageFormat for plurals (Polish/Czech/Ukrainian have 3–4 plural forms and one/few/many/other categories that break naive if (n==1) code); allow +40% text expansion in every button; German compound nouns will break your ticket layout.
• Print language ≠ UI language ≠ guest language. Menu items need a per-station translation column (r01 §2.7) — a schema decision, not an architecture one.
• RTL (Arabic/Hebrew) is not needed for the beachhead. Defer, but use logical layout properties (start/end) so it is a config change later, not a rewrite.

#5.5 Colour-blind-safe KDS

~8% of men and ~0.5% of women of Northern European descent have a colour-vision deficiency, predominantly deutan/protan [known]. A KDS that encodes "late" as red and "on time" as green is unreadable to one cook in twelve.

Rules:

• Never encode state in hue alone. Every ticket carries a numeric elapsed timer (mm:ss) as the primary signal.
• Add redundant channels: border weight (2 px → 6 px), position (late tickets sort left/top), and a fill pattern or an icon.
• If you use a colour ramp, use blue → amber → magenta, not green → amber → red. Both deutans and protans distinguish it.
• All text ≥ 4.5:1 contrast against its ticket background after the state colour is applied — the amber state is where teams fail this.
• Validate with a deutan/protan simulator in CI on screenshot tests; it's a 0.1 eng-month check that prevents a class of bug you will otherwise never hear about (cooks do not file tickets).

#5.6 Tip screens

• In a semi-integrated payment flow — which is what you should ship (r01) — the tip prompt is rendered by the payment terminal's own app (Adyen, SumUp, Viva, Nexi, PAX), not by yours. You configure the presets via the terminal API and read the tip amount back. You do not control that UI. Design accordingly: your CFD shows the total, the terminal shows the tip prompt, your ticket reconciles.
• Full control of the tip UI requires a fully-integrated flow or your app running on the terminal, both of which pull you into PCI scope. Not a v1 move.
• Beachhead reality: tipping is 5–10% in PL/CZ/UA and increasingly card-based; in DE/AT rounding-up is the norm; in FR/ES service is included. Default presets must be per-country, and CEE defaults should be lower than any US-derived library's.
• Do not pre-select a tip percentage and do not use a "no tip" option rendered smaller or greyer. Beyond the reputational issue, pre-ticked defaults are a live consumer-protection question in the EU [estimate — worth 30 minutes with counsel].
• Tips have fiscal and payroll consequences (r03 §4). The client's job is to record tip_amount, tip_method, and tip_recipient; the allocation policy (pooled vs individual) is back-office configuration.

#5.7 Accessibility — where it is legally binding

#6. Cross-cutting engineering decisions

#Build effort

Assumes Kotlin/Compose for counter surfaces and React/TS for web, per §2.4. Excludes the offline/sync core (r04), the printing stack and hardware certification (r01), fiscal drivers (r03), CRM/loyalty backend (r06), payments integration/certification, and all backend services. AI assistance is assumed and already baked in at roughly 1.5× on web/CRUD, 1.15× on native/device/perf work, 1.0× on UX decisions and on-site debugging [estimate] — AI is close to useless for "the Sunmi service unbinds after 4 hours idle".

#Minimum team shape

Roles that are not optional at any funding level: (1) one QA engineer with a physical device lab; (2) one designer who has either worked on a POS or will work 20 restaurant shifts; (3) by customer #10, one field/support person who is not an engineer.

#Open questions / what would change this answer

1. Beachhead = CEE or Western EU/US? This is the framework decision in disguise. CEE ⇒ Android AIO at EUR 465–688 dominates ⇒ Kotlin/Compose Android-first is unambiguously right and iPad may never be needed. US/Western EU ⇒ iPad attach rises materially ⇒ React Native becomes the safer pick and the +5.5-month bridging tax becomes the price of insurance. Resolve before the first commit. Verify by asking 15 target restaurants in the beachhead what device they'd expect on the counter and what they'd pay for it.
2. Is Compose Multiplatform on iOS good enough for a POS in 2026? JetBrains marks the UI stable for Android/iOS/desktop as of May 2026 [verified], but "stable" and "a server will not notice" are different bars — text input, scroll physics, and accessibility on iOS are the areas to test. Verify: build the item-grid + ticket screen in CMP, run it on a real iPad for a week, measure p99 frame time and have three servers use it. Two weeks of work that de-risks a EUR 500k decision.
3. Flutter's Impeller on the exact AOSP GPUs we resell. Impeller is the only renderer on modern Android as of 2026 [verified]; Rockchip RK3568 / Mediatek GPU drivers on EUR 465 POS AIOs are not a well-trodden path [estimate]. Only matters if question 1 pushes you toward Flutter. Verify: one afternoon with a Flutter sample on a D3 Mini and an Elo I-Series 4.
4. Do we sell through acquirers on PAX/Ingenico estates? If yes, PAXSTORE distribution and acquirer whitelisting become a 2–6 month business-development dependency [estimate] that gates your entire release process, and sideloading stops being an option. If no, Sunmi + a separate terminal keeps you in control. Verify: one conversation each with a PL and a UA acquirer about third-party app onboarding, before designing the release pipeline.
5. EAA scope: who is the "service provider" for a white-label ordering page? If it's us, the microenterprise exemption never applies and every guest surface must be EN 301 549 conformant from day one (+1.5 eng-months and an ongoing audit obligation). If it's the restaurant, most single-site cafés are exempt and we can ship a lighter v1. Verify with counsel — this is a 2-hour question with a 6-figure answer.
6. MDM: build or buy, and at what scale does it flip? At 6 devices/site, Esper is EUR ~22/site/mo against a EUR 79–129 subscription. Our own agent costs ~2–3 eng-months up front. The flip point is roughly 150–250 sites [estimate]. Verify: get real quotes from Esper, Hexnode, and Scalefusion at 500 and 2,000 device commitments — published list prices are not what you'll pay.