Skip to content

AI for connected device apps

Connected-device apps, made smarter without a rewrite.

We add the AI features that matter in hardware-companion products, on-device inference, natural-language device control, sensor-stream summaries, and predictive alerts, to the app you already ship.

You have a working app. Leadership wants AI in it.

Your app is in production. It pairs with hardware, it holds a real-time connection, and it already handles the messy parts: BLE provisioning, reconnection, firmware quirks, a telemetry stream that never stops. Now leadership wants AI inside it: control the device by talking to it, turn a wall of sensor charts into a sentence, catch the failing unit before the customer calls. The idea is right. The way most shops respond is not.

Every quote you get back starts with "first we rebuild". The real constraint in a connected-device product is not the model, it is the device layer you already got working. The pairing flow, the real-time sync, and the reliability you fought for are not things you casually re-open. And some of these features need to run on the phone or the edge, not a round trip to a server, because a device app cannot always assume a good connection. So we do not rebuild. We add AI as a layer beside your device and telemetry flows, on-device where latency or offline use demands it, and the connection you already trust stays exactly where it is.

What we build

Four AI features that earn their place in a device app.

These are the patterns we see land in hardware-companion products. Each one sits beside your existing device connection and telemetry pipeline, not inside the pairing and sync path you already got right.

On-device inference

Running a model on the phone or the edge instead of a server round trip: classify a signal, detect an event, or read a barcode locally, with low latency and no dependence on a live connection.

What it changes
A feature that had to wait on the network now responds instantly and keeps working offline, which matters when the device is in a basement, a field, or a moving vehicle.
How it is built
A compact model packaged to run on-device, with a server fallback for the heavier cases, so the common path is instant and the rare path is still handled.

Natural-language device control

Letting a user control the hardware by asking for what they want, "set the bedroom to 68 tonight", instead of hunting through screens of settings and schedules.

What it changes
Control that needed several taps and a mental map of your menus becomes one sentence, and the features buried three screens deep actually get used.
How it is built
An intent layer that maps natural language onto your existing device commands, with a confirmation step before anything changes state on real hardware.

Sensor-stream summaries

Turning a continuous telemetry stream into a plain-language readout: trends, anomalies, and a short summary instead of a raw chart the user has to interpret.

What it changes
A user watching a device, or a coordinator watching hundreds, sees the few that moved and what changed, not an endless wall of numbers to scroll.
How it is built
Aggregation and thresholds compute the numbers first; model-generated summaries sit on top and cite the underlying signal so a person can verify.

Predictive alerts and maintenance

Spotting the pattern in a device's telemetry that comes before a failure or an issue, and flagging it as an alert before the customer notices something is wrong.

What it changes
Support shifts from reactive to ahead of the problem, and a customer hears from you before they would have called in frustrated.
How it is built
Anomaly detection over the telemetry history computes a signal first; a model classifies and explains the flag, feeding an alert queue rather than crying wolf on every blip.

Proof

What we have actually shipped for connected devices.

We name only work we can stand behind, and we are precise about who delivered it. The first two are the connected-device track record; the last two are the AI and mobile depth behind the features above.

Carrier SmartHome

Delivered by our team via Toptal

A consumer smart-home app for Carrier that controls physical HVAC hardware (heating, cooling, air purifiers) with real-time two-way sync. Our founder led the team, and the app pairs, provisions, and stays in sync with real devices at scale. On-device camera scanning handles device install.

  • 1M+ App Store downloads
  • Real-time two-way sync over WebSockets and GraphQL, plus BLE pairing and Wi-Fi provisioning
  • Nx monorepo (~7 apps, 22 shared libs) with a 64-component design system across iOS, Android, and web
How we run AI on-device

Nightingale Labs

Delivered by our team via Toptal

A remote-monitoring platform built around an under-mattress bed sensor that continuously reports heart rate and ballistocardiography. Our founder and team built the cross-platform frontend, turning a raw device signal into clinical charts, with QR and camera-based device onboarding.

  • ~40 screen modules across 114 API endpoints
  • A hand-built charting engine rendering device telemetry on web, iOS, and Android from one codebase
  • QR and barcode device onboarding with on-device camera scanning
AI for healthcare apps

The LYVE App

Inseed project, live on both stores

A live mobile product our founder built end to end, from zero to the App Store in under four months, with real-time chat, payments, and a social layer. Proof we ship and maintain complex React Native apps, not just prototypes.

  • 3,000+ users across iOS and Android
  • Real-time multi-tier chat and a Stripe escrow payment flow
  • Zero to the App Store in under four months
How we build with React Native

Playlists

Delivered by our team via Toptal

A live app with an AI search that turns a vague natural-language query into results. The same intent-mapping pattern is what lets a user control a device by saying what they want instead of navigating settings.

  • GPT-4o query enrichment plus embedding-based semantic search
  • Staged matching pipeline that always returns usable results
  • Reported +200% growth in AI-driven searches after launch
Read the Playlists case study

Straight answer on the gap: our connected-device track record is genuinely strong on the app side, real-time two-way device sync and BLE provisioning at Carrier (1M+ downloads), continuous sensor monitoring and telemetry visualization at Nightingale. What we have not done as Inseed is ship a custom on-device ML model into one of these apps. At Nightingale the signal ML lived with the backend team, and our scope was frontend and mobile; the on-device work we have shipped is camera and barcode inference for device onboarding. The audit is where we prove on-device inference or device control on your app, in a throwaway prototype, before you commit to a build.

Borrowed proof, labeled honestly

React Native holds up as a hardware companion.

The Tesla app, which controls a car from a phone, runs on React Native. It is not our client. It is proof that a phone-to-hardware control app, with real-time state and real consequences to getting it wrong, holds up on the framework we build on, so the question for yours is the feature, not the foundation.

FAQ

Connected-device questions, answered straight.

Can you add AI without touching our BLE pairing and sync code?

Yes, that is the whole point of how we work. The AI feature sits beside your device connection as a separate layer, reading the telemetry you already stream and issuing commands through the interface you already expose. The pairing, provisioning, and real-time sync you fought to make reliable do not change, so you are adding a feature, not re-opening the device layer.

Does on-device inference actually work in a React Native app?

Yes, for the right kind of model. A compact model can run on the phone or the edge for low-latency, offline-capable inference, with a server fallback for the heavier cases. We have shipped on-device camera and barcode inference in Carrier and Nightingale for device onboarding, and the same packaging approach carries to signal classification when latency or offline use demands it.

How do you keep natural-language device control from doing the wrong thing?

With a confirmation step and a bounded command set. The intent layer maps what the user says onto your existing device commands, not an open-ended set of actions, and anything that changes state on real hardware gets a confirmation before it fires. On physical devices the cost of a wrong action is real, so control is deliberate rather than eager.

Can you handle real-time device data and two-way sync?

Yes, this is squarely our track record. Carrier SmartHome runs real-time two-way sync between the app and physical HVAC hardware over WebSockets and GraphQL, so a change on either side propagates to the other. Nightingale turns a continuous under-mattress sensor stream into live charts across web and mobile. Real-time device state is the part we have already done at scale.

What if the device is offline or the connection is poor?

That is exactly why some of these features belong on-device. On-device inference keeps working without a live connection, and for the server-backed features we design for intermittent connectivity: queue and reconcile rather than assume the network is always there. A device app that falls over the moment the signal drops is not a device app you can ship.

Is React Native robust enough for a hardware-companion app?

Yes, and we can point at live evidence. Carrier SmartHome runs BLE provisioning and real-time HVAC control at 1M+ downloads. Nightingale renders continuous sensor telemetry across web and mobile from one codebase. Beyond our work, the Tesla app controls a car from a phone on React Native.

Ready to add AI to your connected-device app?

30 minutes, free. We will look at your app and tell you honestly where AI fits, what it costs, and what we would build first. Shuhel will be on the call.

Book a 30-minute call