Internet of things means anything that produces data and must be watched or controlled from a distance: a solenoid valve in an irrigation line, an office air conditioner, a cold-chain temperature logger, a factory power meter, a warehouse lock or a fleet of refrigerated vans. IoT app development, though, is not a screen with an on/off button — the application is the last link in a five-part chain running through hardware and sensors, radio and protocol, ingest service, time-series storage and finally the interface. That is exactly what distinguishes PBDP on these projects: a team that understands both the handset and the circuit board, delivering an app that keeps a technician working when the network disappears and then syncs quietly once it returns.

Where an IoT app sits in the system

An IoT product has five layers and the app is only one of them: the device and its sensors, the connectivity (Bluetooth, Wi-Fi, LoRa, NB-IoT or a gateway), the broker or cloud ingest service, the application logic and historical store, and finally the interface — mobile, web or both. Most schedule problems come from treating the interface as a separate contract. We map the whole chain in the first workshop, then design the app against it. Where the hardware is not yet defined, the same team works through IoT hardware development and embedded programming, and the radio and power budget is settled during PCB design rather than discovered at the end of the project.

What you receive

• Companion mobile app: scanning, pairing, live telemetry, remote control with command acknowledgement, firmware update handoff and a per-device configuration screen.
• Connectivity layer: Bluetooth Low Energy services and characteristics implemented as a documented hardware and software integration contract, alongside MQTT or HTTPS transport with TLS, retries and a resumable queue.
• Dashboards and history: charts, thresholds, period comparisons and export, delivered as a web application for operations teams and supervisors.
• Alerting: escalation rules by severity, channel and on-call rota, with quiet hours and acknowledgement tracking so warnings are acted on rather than ignored.
• Offline behaviour: local caching, buffered telemetry and conflict resolution for technicians who work in basements, fields or steel buildings.
• Device management: provisioning, key rotation, ownership transfer, fleet status and remote diagnostics for support staff.
• Release and quality pack: signed builds, test reports on real devices in real radio conditions, and store listings via app store publishing and ASO.

The process, from signal to screen

1. Scenario definition: who holds the phone, what they must do within thirty seconds, and what happens when a reading never arrives.
2. Data contract: message schema, units, timestamps, quality flags, sampling rates and retention — agreed in writing before anyone codes.
3. Interface design: UI/UX design built around status legibility: what is online, what is alarming, what needs a decision now.
4. Parallel build: firmware, ingest service and client developed together against the contract, with device simulators so the app is never blocked waiting on hardware.
5. Field validation: range tests, interference, cold starts, battery drain, disconnected networks and drop-out behaviour measured on site.
6. Launch and care: staged rollout, monitoring message success rates, then an agreed plan of app maintenance and updates as firmware revisions land.

Protocols, provisioning and the honest hard parts

The interesting failures in IoT are rarely in the interface. They are in pairing — the moment a user must connect a phone to a device with no screen and no keyboard — and in connectivity assumptions. Our approach: a provisioning flow designed for a first-time user who has not read a manual, discoverable service identifiers, a fallback path over sound or QR when Bluetooth is switched off, and clear state feedback at every step. On transport, Bluetooth Low Energy suits local configuration and short bursts, MQTT suits continuous telemetry with quality-of-service levels, and HTTP fits sparse readings from devices behind gateways; many products legitimately need two of the three. Payload size matters more than teams expect, because every extra byte shortens battery life and multiplies across a fleet. Where the goal is foresight rather than visibility, the collected telemetry becomes input to forecasting models; and security is specified in the same document as the screen layouts — unique device credentials, certificate-based mutual authentication, signed firmware and a revocation path — then reviewed before a fleet goes live.

Frequently asked questions

Do you build the hardware too, or only the app?

Both are available. Some clients arrive with a working board and need only the companion application; others start from a concept and we take it through electronics, enclosure and firmware. The important point is that the radio protocol and the mobile client are designed together — an app can only ever be as reliable as the contract it shares with the device.

Can one app manage many different device types?

Yes, and it should. We build a device abstraction with a capability model, so a thermostat, a meter and a tracker share scanning, pairing, authorisation and history screens while exposing only the controls each one actually supports. That is what keeps the interface simple as the catalogue grows, and it also makes a shared codebase an attractive delivery route.

What is the main cost driver in an IoT app project?

Integration breadth rather than screen count. Each protocol, each device family, each cloud service and each offline requirement multiplies the size of the test matrix. A single-device companion app can be delivered in a few weeks; a multi-family fleet platform with alerting and a supervisor console is a phased programme, and we price it in phases so a first working version reaches users early.

To scope an IoT application — from pairing flow to cloud ingest — contact PBDP with your device datasheet, or send nothing at all and we will start from the use case; the service list shows which engineering disciplines sit behind this page.