Mobile Device Management (MDM) is one of those categories where commercial solutions dominate — and for good reason. Products like VMware Workspace ONE, Microsoft Intune, and SOTI MobiControl have mature feature sets, broad device support, and enterprise-grade support contracts. For most organizations, one of them is the right answer.
But most isn't all. And when a client came to us managing a fleet of 200+ Android devices in a logistics operation, we quickly realized that the off-the-shelf options weren't going to cut it.
The client ran a last-mile delivery operation. Their drivers used rugged Android devices — Zebra TC-series handhelds — to receive assignments, capture proof-of-delivery signatures, scan barcodes, and report exceptions. The devices never left company hands; they were checked out at shift start and returned at end of day.
On paper, this sounds like a textbook MDM use case. Lock down the device to a kiosk app, push policies, done. In practice, their requirements turned out to be highly specific in ways that standard products handled poorly.
First, the assignment system. Drivers were assigned to specific routes, and the device needed to know — in real time — which driver had it. Not just for authentication, but for routing: the app had to pull the correct route package the moment a driver scanned their badge. Standard MDM products treat devices as the unit of management; user-to-device assignment at the session level isn't a first-class feature.
Second, offline resilience. Delivery routes often passed through areas with spotty connectivity. The device needed to cache the full route manifest locally and sync state changes (signature captures, barcode scans, exception flags) when connectivity returned. MDM agents generally assume persistent connectivity for policy enforcement — and policy failures in offline mode often mean the device locks up at exactly the wrong moment.
Third, compliance reporting. The client's operations team needed real-time visibility: which devices were on-route, which had missed a scan checkpoint, which had low battery. The reporting APIs in commercial MDM products are designed for IT compliance — software versions, policy status — not operational telemetry.
We evaluated three commercial products seriously. All three had gaps in at least two of these areas. The workarounds their sales teams proposed involved middleware, custom API bridges, and professional services engagements that would have cost more than building from scratch — and still wouldn't have given us the offline behavior we needed.
So we built a custom MDM. Here's what that actually looked like.
The core of the system is an Android Device Policy Controller (DPC) built using Android's Device Owner API. This is the same API that commercial MDM products use; it gives us full device control — lock screen, app whitelist, network policy, system update control — without any dependency on a third-party agent.
The DPC communicates with a backend service we call the Fleet Management Server (FMS). The FMS is a relatively simple service: it maintains device state, handles driver-to-device assignment, and serves as the source of truth for route packages. We built it on a Node.js backend with a PostgreSQL database, deployed on the client's existing AWS infrastructure.
Route packages are cached on-device using a local SQLite database. The sync protocol is designed to be resumable — if a sync is interrupted mid-transfer, the device picks up where it left off rather than starting over. State changes (scans, signatures, exceptions) are queued locally and flushed to the FMS opportunistically whenever connectivity is available.
For operational telemetry, we instrumented the DPC to emit heartbeat events every 60 seconds: GPS position (when available), battery level, active route package, last successful sync timestamp. These events go to a separate telemetry pipeline — Kinesis Data Streams into a simple dashboard — so operations staff can see fleet status without querying the MDM.
Driver assignment is handled via NFC badge tap at shift start. The device reads the driver's badge ID, authenticates against the FMS, and pulls the appropriate route package. The whole flow takes under three seconds. At shift end, a second tap logs the driver out and queues a final sync.
The build took about three months with a team of three: one Android engineer, one backend engineer, and a part-time infrastructure engineer. Ongoing maintenance is handled by one part-time engineer. The total cost over two years — build plus maintenance — is meaningfully lower than what the commercial alternatives would have cost, even before accounting for the customization gap.
Performance has been solid. The fleet runs 200+ devices across three warehouses. In eighteen months of operation, we've had two incidents requiring remote intervention: one corrupted SQLite database (fixed via remote wipe and re-provision) and one firmware update that broke the NFC reader on a specific device batch (resolved by pinning that model to a prior firmware version).
What didn't go well: the initial driver UX for the NFC tap flow was confusing — drivers were tapping at the wrong point in the boot sequence, which caused assignment failures. We fixed it with a persistent visual prompt during the boot animation, but it took us two iterations to get right. MDM-level UX is harder than app UX because you have less control over the environment.
We also underestimated the complexity of supporting multiple Android versions across device generations. The client's fleet spans Zebra devices running Android 10 through 13, and the Device Owner API has subtle behavioral differences across versions, particularly around Work Profile behavior and notification policy. Building a robust device compatibility matrix early would have saved us debugging time later.
The honest recommendation: if a commercial MDM fits your requirements, use it. The maintenance burden of a custom solution is real, and the major commercial products have earned their market position. But if your use case has specific operational requirements that commercial products treat as edge cases — offline resilience, session-level user assignment, custom telemetry — a purpose-built DPC can be both more capable and more cost-effective than forcing a generic product to do something it wasn't designed for.
The key question to ask is not "can the commercial product do this" but "how much will it cost to make the commercial product do this the right way" — and compare that honestly against the cost of building a focused solution that does exactly what you need.