All Services

    IoT App & Cloud Development

    Mobile apps, web portals, and scalable IoT cloud backends that connect your product, its data, and the people who use it.

    A connected product needs more than hardware. It needs a place to receive, store, and process device data, plus an interface that turns that data into something useful.

    We build the software around connected hardware: mobile apps, web portals, IoT cloud backends, device management, and the data pipelines that connect them.

    What We Build

    Mobile Applications

    Cross-platform iOS and Android apps in React Native, built around the connected product itself: device onboarding and configuration, live data, notifications, account management, and remote device interaction.

    IoT Cloud Backend

    Cloud infrastructure for device connectivity, provisioning and management, telemetry storage, REST APIs, OTA updates, and data pipelines for analytics or ML. Built to move from a pilot fleet to production without replacing the underlying architecture.

    Web Portals & Dashboards

    React and Next.js portals for device maps, fleet health, live and historical data, alerts, user roles, and firmware update management.

    One Connected System, From Device to Dashboard

    An IoT app does not sit separately from the device. Firmware decides what data exists, connectivity determines how it moves, the cloud decides how it is stored and processed, and the app determines what users can actually do with it.

    We design those layers together, so APIs, payloads, authentication, OTA updates, and user workflows are agreed as one architecture rather than connected afterward.

    1. Connected Device
    2. BLE / Cellular / Wi-Fi / other connectivity
    3. IoT Cloud & Device Management
    4. APIs & Data Processing
    5. Mobile App / Web Portal / External Systems

    Our Cloud Development Approach

    Our cloud architect works alongside the embedded engineers who write the device firmware. The API between device and cloud is designed with the constraints of both sides in mind. Message payload structures are optimised for bandwidth-constrained cellular connections. Authentication flows work within the limitations of resource-constrained MCUs. The cloud system is designed as one coherent system with the hardware, not bolted on after.

    How an App & Cloud Project Runs

    1

    Architecture & requirements

    We map the device, connectivity, users, data flows, and integrations before choosing the software architecture. That includes what needs to happen on the device, in the cloud, and in the app.

    2

    Build the connected flow

    We build device onboarding, telemetry, APIs, and the first user workflows together so we can test the full path from hardware to interface early.

    3

    Test with real hardware

    We test against the actual device and real connectivity conditions, including connection loss, reconnection, delayed data, and firmware changes.

    4

    Prepare for production

    Before launch, we build in monitoring, device management, OTA workflows, and deployment processes so the system can support a growing fleet.

    We test the software with the hardware, not against a simulated device forever.

    When Edge ML Makes More Sense Than Sending Everything to the Cloud

    Some IoT products are smarter when the intelligence sits on the device, not only in the cloud. We build trackers that run lightweight ML models on board: activity classification, anomaly detection, schedulers that decide when a measurement is worth taking. Hardware, firmware and model are designed together, so the device only sends data that actually matters.

    • Lightweight inference on nRF91-series MCUs and other low-power targets
    • Sensor fusion and time-series classification trained on real field data
    • Multi-tenant cloud platforms to ingest, store and serve the telemetry
    • Explainable outputs (SHAP, decision logs) so operators can trust what the device says
    • AI architecture and documentation designed with applicable EU AI Act requirements in mind

    Security Across the Device Lifecycle

    IoT security starts before data reaches the cloud. We design device identity, authentication, encrypted communication, access control, and OTA updates as part of the system architecture.

    Typical implementations include unique device credentials, TLS-encrypted transport, cryptographically verified firmware updates, and role-based access for users and operators.

    1. Device identity
    2. Secure transport
    3. Access control
    4. Secure OTA

    Built Into Real Products

    PadelPlay

    Sensor → Bluetooth → mobile app → cloud analytics

    PadelPlay streams sensor data from a racket to a mobile app and cloud-based analysis. Real-world Bluetooth interruptions led us to build buffering, reconnection, and replay logic so complete sessions still reach the cloud.

    Read the PadelPlay case study

    MedeMeter

    Sensor → LTE-M → cloud → dashboard

    MedeMeter combines on-device processing with cellular connectivity and cloud infrastructure. Only useful computed data leaves the sensor, while the cloud supports dashboards and wider data sharing without transmitting raw audio.

    Read the MedeMeter case study

    From Pilot to Production

    A pilot and a production fleet have very different needs. We keep early systems lean enough to validate the product quickly, while making the architecture decisions that matter later: device identity, fleet management, monitoring, OTA, data storage, and deployment.

    The goal isn't to over-engineer the first 50 devices but to avoid rebuilding everything when the product succeeds.

    Scope the app around your device and its users

    An IoT app has to work with a physical product: pairing, interrupted connections, battery limits and devices running different firmware versions. We define those interactions alongside the screens and cloud services.

    Start with one complete user journey

    Describe how a user installs the app, connects a device and gets useful data. Include what happens when the phone is offline, Bluetooth disconnects or an upload fails.

    Set the boundary of the first release

    Agree mobile platforms, device protocol, backend APIs and dashboard functions. Account roles, alerts, integrations and firmware update management should each have an explicit place in the scope.

    Make ongoing costs visible

    Device count, message frequency and data retention affect cloud usage. Discuss hosting, monitoring, third-party services and maintenance separately from the initial development budget.

    Bring your hardware information

    An existing firmware build, protocol description or working prototype helps us assess the connection. If the electronics are still being developed, we can define that interface with the hardware and firmware team.

    Frequently asked questions

    What does developing an IoT app cost?

    The scope determines the estimate: mobile platforms, the device connection, backend services, user roles and integrations. We agree a first release and separate development from ongoing hosting and maintenance. Share your existing hardware and protocol information to make the estimate more specific.

    Can you connect an app to our existing hardware?

    We can assess an existing device and its firmware protocol. A working prototype, interface documentation and access to the relevant firmware help us identify what can be reused and what needs to change.

    Can you build both the mobile app and web dashboard?

    Yes. We build cross-platform mobile applications and web portals for device monitoring, administration, alerts, data visualisation, and fleet management.

    How do you connect the hardware to the cloud?

    The architecture depends on the device and connectivity model. We define the device API, payload structure, authentication, data ingestion, and storage, along with the firmware requirements, so the device and backend are designed as one system.

    Can you support OTA firmware updates?

    Yes. OTA infrastructure can include firmware delivery, version management, device targeting, and cryptographic verification, coordinated with the embedded firmware.

    Can the same system grow from a pilot into production?

    That's the goal. We keep the first version lean enough to test the product while designing the parts that become difficult to replace later, including device identity, APIs, data models, and fleet management.

    Does the app need a cloud connection?

    That depends on the user journey. A direct Bluetooth connection can cover nearby device interaction. Remote access, shared histories and fleet dashboards usually need backend services. We define offline behaviour and synchronisation as part of the scope.

    What should we agree before development starts?

    Agree the supported devices and mobile platforms, the first user journey, account roles, data retention, acceptance tests and deployment responsibilities. Include ongoing cloud costs and maintenance so the launch budget reflects operation as well as development.

    We needed a way to get data from solar systems in off grid villages into our cloud. Not exactly a friendly environment to design for. Power is unreliable, conditions are tough, connectivity is limited at best. Insyght moved fast and delivered a solution that just works, with solid Bluetooth connectivity and no unnecessary complexity.

    Evan Mertens
    Evan MertensCTO at Spark Energy
    Read the case study

    Explore More Services

    Previous
    Firmware Development
    Next
    Electronic component sourcing & factory qualification

    Tell Us About Your IoT Product

    From mobile app to cloud backend. We build the software stack for connected hardware.