IoT application development: mobile apps, device connectivity and cloud back ends for connected products

We build the software side of connected products: the iOS, Android and React Native apps that pair with a device over Bluetooth Low Energy or beacons, the MQTT and cloud back ends that collect what it reports, and the dashboards, payments and admin tools around it. Our project records hold 15+ connected-device projects, from a personal safety beacon to an in-car device app and a sauna controller.

Get a quoteBook a project call
A small connected device with an antenna beside a phone showing a pairing screen, on a workbench

What we build for connected products

Examples from our own projects, described in general terms. Firmware stays with the hardware team; we build everything the device talks to.

Device-connected mobile apps

iOS, Android and React Native apps that scan, pair and talk to a device over Bluetooth Low Energy or iBeacon, including background connectivity within what each platform allows. See Silent Beacon and Drive lah.

Device protocols and security

The command set agreed with the hardware team, encryption on the link where the device allows it (AES-CBC with CRC checks on an in-car unit), and pairing flows that recover when the connection drops.

MQTT and cloud back ends

Devices that publish over MQTT, cloud functions that act on what they report, and the APIs behind the apps, on AWS or Firebase. See the sauna controller and the vehicle recovery app.

Dashboards and admin panels

Web panels to see devices, users and events, with the reporting a product team needs once units are in the field.

Payments and subscriptions on devices

In-app purchases, Stripe and card readers in the apps around the device, as in the sauna controller and the vehicle recovery app.

Readings, sync and offline behaviour

Apps that read a scale, a wearable or a sensor, keep working offline and reconcile when the link returns. See FitMi and TechnoGarden.

When to bring us in

We fit best when the hardware exists or is being built by a partner and the product needs its software:

  • A device with Bluetooth, and an app that must pair with it, control it and show what it reports.
  • Equipment in the field that should publish readings over MQTT to a cloud back end, with alerts and a dashboard.
  • A connected product that also needs accounts, payments or an admin panel.

If you are still choosing a platform, our guide to how connected products work and how to choose a platform covers the trade-offs. For the mobile side on its own, see mobile app development.

Apps and back ends that talk to hardware: personal safety beacons, smart scales, formula machines, in-car devices and sauna controllers.

Silent Beacon: personal safety apps and web portal screenshot

Connected-device project

Silent Beacon: personal safety apps and web portal

  • Public safety and government
  • Mobile apps
  • Web apps
  • Integrations

2016–2024

Android and iOS apps, a backend and a web portal for the Silent Beacon Bluetooth safety beacon: alerts, live location, subscriptions and business accounts, maintained over eight years.

FitMi app icon linked by Bluetooth to a smart scale, above icons for weight, planner, food log, pairing, activity and sleep

Connected-device project

FitMi: smart-scale nutrition and exercise tracker

  • Healthcare
  • Mobile apps
  • Integrations
  • Web apps

2016–2018

FitMi, native iOS and Android apps that weigh food on a Bluetooth smart scale, log meals with nutrition data and track weight, sleep, water and exercise.

Three Diluo app screens: warming up, ready to brew, and brew-type settings

Connected-device project

Diluo: Wi-Fi formula machine apps and cloud admin

  • Healthcare
  • Mobile apps
  • Web apps
  • Integrations

2013–2014

iPhone and Android apps for Diluo, a Wi-Fi baby-formula brewing machine, with child profiles, diary and statistics, plus a Rails cloud admin and API behind them.

Drive lah: car-sharing app connected to an in-car device

Connected-device project

  • Logistics and transport
  • Mobile apps
  • Integrations

2021

A React Native app for iOS and Android that talks to an in-car IoT device over Bluetooth Low Energy, with AES-CBC encryption, CRC checks and a back-end API.

Android app that controls sauna tubs over MQTT

Connected-device project

  • Brand and business sites
  • Mobile apps
  • Integrations

2017–2018

An Android app for a wellness equipment maker: temperature and feature control of sauna tubs over MQTT, video content, and payments through a card reader and Stripe.

Stolen-vehicle reporting and beacon-scanning app

Connected-device project

  • Public safety and government
  • Mobile apps
  • Web apps

2019–2020

An iOS app on Firebase for reporting stolen cars and tracking recovery, with beacon scanning to identify vehicle devices, in-app purchases, maps and a web admin panel.

iBeacon trip tracking with background connectivity

Connected-device project

  • Logistics and transport
  • Mobile apps

2019

An Android app that keeps a stable connection to iBeacon devices in the background and when the phone is locked, starting and finishing trips as beacons come into and out of range.

All case studies

Articles

Guides from our team on the questions buyers ask about this service.

All articles

Technologies we use

The device links, platforms and back ends our connected-device work runs on. Linked technologies open our page for them.

Frequently asked questions

Do you build the firmware as well as the app?

We build the app, the cloud back end and the integration with the device. Firmware stays with the hardware team, and we agree the protocol with them: which commands the device accepts, how it reports state, and how pairing and security work.

Bluetooth Low Energy, Wi-Fi or cellular?

Bluetooth Low Energy suits a device that is used next to a phone, such as a wearable or an in-car unit. Wi-Fi or cellular with MQTT suits equipment that must report when nobody is nearby. Many products use both: BLE for set-up and local control, the cloud for everything else.

How do you handle pairing and security?

Pairing flows are designed around the device: scanning, selection, confirmation and recovery when the connection drops. Traffic to the device is encrypted where the hardware allows it, as in our in-car device app with AES-CBC and CRC checks, and the cloud side should hold credentials per device rather than one shared key.

What happens when the device is offline?

The app keeps working with the last known state, queues commands where that is safe, and reconciles when the connection returns. Background connectivity on Android and iOS has limits, and we design within them rather than promising what the platforms will not allow.

How does a project start?

With a short pilot: one device, one app flow, one cloud path, so both teams see the protocol working before the full build. We sign an NDA before work starts, and you own the code we write for you.

How can we work together?

There are three ways, on the same terms:

  • Dedicated team, best for ongoing work: interview the developers, then they work on your project full or part time.
  • Fixed scope, best when requirements are clear: we agree the scope and the price up front, and deliver against it.
  • Time and material, best when the scope will change: you pay for the time used and can change priorities as the work goes on.

Whichever you choose, we sign an NDA before work starts, you own the code we write, and every change is reviewed in your repository.

Can I interview the developers before we start?

Yes. For a dedicated team you meet the developers in an online call and interview them before they join your project.

Building a connected product?

Tell us about the device, who makes it and what the app and cloud side must do. We come back with questions, a suggested pilot and a proposal.