Industry · IoT

Mobile and Backend Software for IoT Platforms

Connected products continuously generate data — and new obligations. Since the EU Data Act (applicable 12 Sep 2025) manufacturers must enable structured data access for end customers. From the Cyber Resilience Act (fully applicable 11 Dec 2027) every connected product on the EU market must meet binding cybersecurity requirements.

Contact

Industry context

IoT applications typically span four layers: devices (sensors, actuators), a connectivity layer (BLE, MQTT, NB-IoT, LoRa), a data layer (telemetry ingestion, time-series database), and an application layer (mobile app, dashboard, alerts). Beyond a certain device count, the backend platform — not connectivity — becomes the bottleneck.

In 2026 two regulatory currents converge for DACH Mittelstand IoT: data sovereignty (EU Data Act, end-customer data access right) and cybersecurity-by-design (Cyber Resilience Act, with fines up to €15 million or 2.5% of global annual turnover). Architecture decisions made now shape the compliance posture for the next 5–10 years.

Typical challenges

Spreadsheets instead of a platform

Many B2B IoT initiatives start with spreadsheets, email attachments, and manual reports. That doesn't scale past a few hundred devices and makes EU Data Act access rights impossible to fulfil.

Retrofitted cybersecurity

Devices shipped without an update mechanism, without encryption, and without vulnerability reporting must be retrofitted for CRA — or taken off the market.

Connectivity silos

The app speaks one protocol, the backend another, legacy devices a third. Without a clean protocol bridge (e.g. MQTT-to-HTTP), every extension turns into plumbing work.

Regulatory framework

EU Data Act

Glossary →

Regulation (EU) 2023/2854 grants users of connected products the right to access, use, and share the data generated through their use. Manufacturers must design devices and related services so this access is technically possible.

Applicability: Applicable since 12 September 2025

Cyber Resilience Act (CRA)

Regulation (EU) 2024/2847 mandates security-by-design for all products with digital elements on the EU market: vulnerability handling, security updates, conformity assessment, incident reporting. Fines up to €15 million or 2.5% of global annual turnover.

Applicability: In force since 10 Dec 2024 · Reporting obligations from 11 Sep 2026 · Fully applicable 11 Dec 2027

DSGVO / GDPR

Glossary →

Telemetry streams often contain personal data (location, usage patterns). The entire data model must be GDPR-compliant — from collection through retention to the right to erasure.

Architecture pattern for B2B apps

Edge & devices
Open connectivity standards (BLE, MQTT 5, NB-IoT, LoRaWAN) · certificate-based device auth · signed firmware update channel

Bidirectional connection with device authentication (X.509 certificate or pre-shared key) and a reliable update mechanism — the prerequisite for CRA conformity. Protocol choice depends on range, power budget, and existing device hardware.

Telemetry ingestion
MQTT broker · WebSocket · typed ingestion API (e.g. NestJS, Fastify, Go) · async job queue

High-throughput device data intake, cleanly separated from the application API. Background jobs for aggregation and alerting. Language and framework chosen by telemetry volume, latency budget, and team — we ship TypeScript, Go, and Rust in production.

Data & lifecycle layer
Relational DB + time-series extension (PostgreSQL + TimescaleDB · alternatively ClickHouse, InfluxDB) · cache · append-only event log

Structured lifecycle data (birth snapshot, service history) plus time-series telemetry. Auditability via an immutable event log. Postgres + TimescaleDB is our default; for very high write volumes we reach for ClickHouse or Influx.

Mobile & portal layer
Cross-platform app (e.g. Flutter, React Native) · web portal · OIDC-based auth (e.g. Authentik, Keycloak, Auth0)

One codebase for iOS/Android, a self-service portal with structured data export (Data Act ready), an admin cockpit for service. We typically reach for Flutter and add native bridges where the BLE stack demands it.

How we pick the stack

The concrete stack is decided per project — driven by data volume, compliance, existing systems, and team skills. This table lists the capabilities we cover and two to three tools we have shipped in production for each.

Capability How we deliver it
Cross-platform mobile with native hardware bridges

One codebase, native modules for BLE and sensor I/O. Typical pick: Flutter with native bridges; pure Swift/Kotlin where the hardware path demands it.

High-throughput telemetry backend

MQTT, WebSocket, event-sourced. Typed backends — shipped in TypeScript (NestJS, Fastify), Go, and Rust. Language follows volume, latency, and team skills, not the other way around.

Hybrid relational + time-series storage

Postgres + TimescaleDB in one database for most cases. ClickHouse or InfluxDB where write volume or analytical load demands it. Paired with an append-only event log as an audit layer.

Open IoT connectivity standards

MQTT 5, BLE, NB-IoT, LoRaWAN — vendor-neutral by design. Avoids lock-in at the device and protocol layer; stays interoperable when the hardware supplier changes.

EU-hosted infrastructure

Compute and database in an EU region. We have shipped on Hetzner, DigitalOcean (Frankfurt), AWS Frankfurt, and Azure Germany among others — the choice depends on data sovereignty, existing contracts, and in-house SRE skills.

Concrete project in this industry?

We build software that fits the regulatory, technical, and organisational realities of your industry — without excess complexity.

Send email