IoT Software Development Services: How We Build the Software Layer of a Connected Product (OBD-II Telematics and a BLE Wearable)

Disclosure: I work at Fly IT Solution, a custom software company. This post describes how we deliver IoT software and uses two of our builds as examples.

IoT software development services cover every layer of a connected product except the hardware: the integration that talks to the device, the back end that receives and stores its data, the mobile app and web dashboard people use, and the admin tools that manage devices, services and subscriptions. This post explains how we structure that work, with two delivered examples: an OBD-II vehicle tracking platform and a Bluetooth Low Energy companion app for an FDA-cleared wearable.

What "IoT software" means in practice

Most connected products have the same five parts, whatever the device is.

1. The device link. Telematics units report over cellular to a server; wearables and sensors usually talk to a phone over Bluetooth Low Energy.
2. The ingestion back end. A service that receives device data, validates it, stores it and streams it to the apps.
3. The app. What the end user opens every day: a map, a score, a device control, a calendar.
4. The admin. Where the operator enables and disables devices, manages subscriptions and runs reports.
5. The intelligence layer. Rules first (a speed threshold), models later (a driving score, a suggestion).

When a client asks for "an IoT app", the first job is to find out which of these five they already have. Usually, it is the device and nothing else.

Build 1: OBD-II vehicle tracking, device to app to admin

An OBD-II device plugs into the vehicle's diagnostic port and reports position and vehicle data. We built the software around it.

What we delivered

• Native iOS and Android apps with real-time tracking, trip history and trip maps
• Speed alerts pushed to the app when a vehicle exceeds a set threshold
• Driving scores per driver, with history, and a driving report for a period
• A Node.js back end that receives and processes device data and serves the apps
• A web interface where the operator enables or disables any OBD device's services and manages subscriptions

Three decisions that mattered

Device state lives on the server, not in the app. Whether a device's service is enabled, suspended or billed is decided in the admin and enforced in the back end. The app only reflects it. That is what makes subscriptions and support workable at scale.

Ingest first, compute later. Raw device events are stored as they arrive. Alerts, trips and scores are computed from the stored stream, so a scoring change never requires the device to resend anything.

Scores need history before they need a model. The first version of the driving score was a rule set over speed events and trip data. A model only makes sense once there are months of real trips to train and validate on.

Build 2: a BLE companion app for an FDA-cleared wearable

The second build is a healthcare MVP delivered for a UK government-backed program. The device is a compact wearable, FDA-cleared by its maker, using patented micro-pulse technology designed for period pain. It has no screen; the phone is the interface.

What we delivered

• A mobile app that pairs with the wearable over Bluetooth Low Energy and controls it directly
• Menstrual cycle tracking with a custom calendar for symptoms, sessions and reminders
• AI-generated nutrition suggestions informed by the user's cycle and usage data
• In-app subscription plans and management

Three decisions that mattered

The device maker holds the regulatory clearance; the software is built around it. We did not touch the device firmware. The app's job is reliable pairing, clear control and the daily features that keep people using the product.

BLE reliability is a product feature. Reconnection after the phone sleeps, pairing on first run and clear "device not found" states took more design time than any screen. If the connection is flaky, nothing else in the app matters.

AI features earn their place by being specific. A nutrition suggestion tied to where the user is in their cycle is useful; a generic chatbot is not. The AI layer reads the data the app already has.

The architecture we reuse

Both builds, and most connected products, fit one shape:

Device ──(BLE or cellular)──► Ingestion API (Node.js)
                                       │
                            Event store (PostgreSQL / MongoDB)
                                       │
          ┌────────────────────────────┼────────────────────────────┐
          │                            │                            │
   Mobile app                    Web admin                  Intelligence layer
   (native / React Native)       (React)                    rules → scores →
   live data, control,           devices, services,         suggestions, anomaly
   history, calendar             subscriptions, reports     detection (Python / AI APIs)

The parts that change per project are the device protocol and the app's daily feature. The ingestion, admin and subscription layers are close to identical, which is why a first release can be scoped tightly.

What an IoT MVP should contain

A first release that is worth shipping has five things: one device type integrated and reporting real data; a back end storing that data; one app the end user will open daily; an admin that can enable, disable and bill a device; and one alert or rule that proves the data is useful.

Everything else, including models, more device types, and a second app, follows once real data is flowing. We write about this sequence on our MVP software development page.

Questions worth asking any IoT software vendor

• Have you shipped a product on this device link (BLE, cellular telematics, gateway) before?
• Where does device state live, and how is a device suspended when a subscription lapses?
• How do you handle reconnection and pairing failure in the app?
• What does the first release contain, and what is deliberately left out?
• Who owns the code, the app store accounts and the data at the end?

How we work

Projects start within 48 hours of agreement, with weekly progress reports and test builds, fixed-price or hourly billing, a written quote within 24 hours of a free consultation, and full code ownership. We build the software, not the hardware, and work with the device you have chosen or help you evaluate off-the-shelf units.

The full-service description, stack and FAQ are on our IoT software development services page. Native versus cross-platform for the app is covered in this comparison, and teams with their own engineers can hire dedicated developers instead of commissioning a project.

If you have a device and a sketch of the app, book a free consultation and we will map the device, the data and the apps with you.