Build IoT & device software

Once a device is in someone's hands or out in the field, you cannot just hotfix a web page. An update has to install cleanly or not at all; a lost device has to be wiped; a scanner has to keep working when the network drops; and security has to hold, because the device itself is the front line. This is a different discipline from building a website: closer to the metal, with real consequences when something goes wrong.

We take on this kind of hard, low-level work. We build the operating systems, app stores, provisioning, security and companion software that make connected products dependable, whether the device is a phone, a handheld scanner or a connected safety instrument. We also stay to support them, because hardware lives for years and the software has to live with it.

The projects we have shipped show what is at stake. On Raw Control, wiping a phone when its SIM is pulled is only useful if the logic holds at the exact moment someone is trying to defeat it, and a lab test does not prove that. On the Datalogic-integrated field app, buffering a scanning session offline matters on the day a warehouse loses connectivity for hours. We design for that day, because on hardware it eventually comes.

Every engagement starts the same way, whether the target is a phone, a handheld scanner or a connected instrument: a discovery workshop maps the hardware, its constraints and its failure modes before any code is written, and we decide on update strategy, offline behavior and security boundaries there instead of iterating them in later. From that point the work splits across four disciplines: operating-system and app-store engineering, provisioning and device management, device-level security, and field integration with the hardware itself. A given project rarely touches all four in equal measure (Mudita's app-store ecosystem leans on the first, the Datalogic-integrated field app on the fourth), but the same team carries the work end to end, so a decision in one discipline, such as how updates install, does not conflict with another, such as how a device gets wiped.

Embedded software development of this kind is judged less on the demo and more on what happens after it: the fleet grows, a new OS ships, a new phone model needs support. We plan for that from the workshop onward, which is also why Mudita, Raw Control and the Datalogic-integrated field app are still active engagements today rather than one-off builds.

The app-store ecosystem for Mudita and the secure phone platform for Raw Control, both detailed above, are in production today, with the store, provisioning and security holding up under real usage.

Beyond phones, we build field software that integrates with scanner hardware (such as Datalogic) and keeps working offline, and companion software for a connected instrument from a global safety-technology company. It pairs with the hardware, handles its readings and keeps the workflow dependable where it is actually used. Across these devices our approach is the same: software built to be dependable on and around hardware, and maintained for the long term. We are still shipping updates and new-device support to platforms we launched years ago.

Underneath, the stack repeats across projects: Android and embedded Linux on the device, Wi-Fi and BLE for connectivity, and backend services that keep the fleet, the store and the admin panel in sync. Working across the same layers on every engagement is what lets one team own a project end to end, rather than handing off between a hardware team and a separate app team.

Getting there in production means treating a release as a two-way door: every update we ship for Raw Control and Mudita has to install cleanly or roll back cleanly, because a device that fails mid-update in someone's pocket turns into a support call. New device models get their own pass through this same install/rollback path before they are added to the fleet, instead of being assumed to behave like the ones already shipped.

We build across the whole device-software stack. Operating systems, app stores, device provisioning, security and hardware integration, shipped for real clients: an app-store ecosystem around a phone (Mudita), a secure phone platform with its own store and device-level security (Raw Control), field apps that keep scanning offline (scanner hardware such as Datalogic), and companion software for a connected safety instrument. We take on hard, close-to-the-metal problems across that whole range.

Because hardware lives for years, we stay: releasing updates, adding support for new devices and OS versions, keeping servers and dependencies current, and handling the steady stream of change requests that a live device platform generates, sometimes for years after the first release. That continuity is why device makers keep working with us long after the first build.

For Raw Control, that continuity looks like this: every new phone model added to the range needs its own path through the provisioning and store pipeline, and every upstream OS security patch has to be checked against the SIM-wipe and nDPI logic before it ships. This work has carried on well past the platform's initial launch. Mudita's App Store and Developer Portal follow the same pattern: developer onboarding and legals get revised as the store's policies and the platform itself evolve.