Field & Mobile Applications for State and Local Government

What this covers

Responders and field staff work from vehicles and on foot, often without reliable connectivity. HQT builds mobile applications that capture data offline, synchronize when connected, and integrate with the agency's systems of record.

Typical activities

Field workflow design based on observation of how work is actually done
Cross-platform mobile development
Offline data capture and conflict resolution on sync
Device management integration and security controls
Mapping and location capture
Integration with CAD, RMS, asset management, or inspection systems

What you receive

Published applications, backend services, device configuration guidance, and user documentation.

Considerations for public agencies

Devices in vehicles face heat, vibration, and theft. Application design accounts for device loss with encryption, remote wipe, and minimal data on the device.

Signals that this work is due now

Field staff fill out paper forms that someone re-keys at the station, so the record exists twice and neither copy is clearly the source of truth.
Staff have built workarounds, such as photographs of a screen or notes in a personal messaging app, because the official system cannot be reached from the field.
A CAD or RMS vendor's mobile client serves sworn staff, while inspectors, code enforcement officers, public works crews, and environmental health staff have nothing comparable.
The remedy for a failed sync is to drive back into coverage or wait until end of shift, so work sits unsubmitted and supervisors cannot see it.
A device refresh is scheduled, or the app stores no longer accept updates to an application built against an old platform target.

What a sound offline design looks like

Treat the device as authoritative until the server accepts the record. That calls for a durable outbound queue that survives a force quit or a dead battery, idempotency keys so a retried submission does not create a duplicate, and conflicts raised for a person to resolve rather than silently overwritten. Reference data the shift will need, such as map tiles, code tables, checklists, and premise history, is downloaded in advance rather than fetched on demand. The interface states plainly what has been submitted and what is still pending.

Weak builds show themselves predictably: a spinner when signal drops, sign-in that needs connectivity at the start of every shift, duplicate records after a tunnel or a canyon, and background sync defeated by the operating system's battery restrictions, so the queue drains only when someone opens the app. Before accepting a build, watch a demonstration in airplane mode that includes a forced crash partway through a form and a sync run once coverage returns.

Where this meets your existing systems and vendors

Most of the risk sits at the seams. Before scoping, get written confirmation from the CAD, RMS, permitting, or asset management vendor about which interfaces exist, what they cost, whether a test environment is available, and whether your contract permits a third party to use them. Mapping usually runs through the agency's GIS, which determines how offline basemaps and feature layers are packaged and licensed. Sign-in should come from the agency's own directory and multifactor service rather than a separate account inside the app. Where criminal justice information is in scope, the CJIS Security Policy sets requirements for encryption, authentication, device management, and personnel screening, with added conditions for access from outside a physically secure location. Peripherals deserve early attention: license scanning depends on the AAMVA card design standard behind the barcode on North American driver licenses, some states limit what may be retained from a scan, and printers, external GPS receivers, and vehicle mounts bring pairing and power problems that appear only in the field.

What to require in the solicitation

Ownership of the distribution chain. Source code delivered to the agency, developer program accounts registered in the agency's name, and signing keys and provisioning profiles held or escrowed by the agency rather than the vendor.
Offline behavior as testable acceptance criteria. Write the scenarios out: signal lost mid-form, a crash with unsaved data, two users editing one record, a sync after an extended outage.
Platform maintenance. An obligation to support new major mobile operating system releases within a defined window, and to keep the platform target current enough that the application remains distributable.
Evidence rather than assurances. Mobile application security testing covering data stored on the device, credential handling, and transport; a CJIS Security Addendum and personnel screening where applicable; and an accessibility conformance report. A public-facing companion should be measured against WCAG 2.1 Level AA, the standard adopted in the Department of Justice rule covering state and local government web content and mobile applications, whose compliance dates depend on the size of the entity.
Records handling in the field. Retention, redaction, and public records response for photographs, notes, and location traces captured on the device.

Working with HQT on this

HQT scopes this kind of work as a fixed-price or time-and-materials engagement with a written statement of work, named staff, and a defined acceptance process. We are candid about what we can take on and prefer a well-run project to an oversized one. Contact us to discuss a requirement, a draft scope, or an upcoming solicitation.

Frequently asked questions

Do we need a native mobile app, or can field staff use a mobile website?

A mobile website is adequate for occasional lookups where coverage is good. Sustained offline work, background location, large map downloads, camera and barcode peripherals, and managed distribution to agency devices are either unavailable or unreliable in a browser. Decide from the work itself: if a shift can pass without usable coverage, an application with a local database is the safer choice.

How should an offline app handle two people editing the same record?

The app should send changes as ordered, identified events rather than overwriting a whole record at sync time. Where a genuine conflict occurs, both versions should be kept and the conflict put in front of a person to resolve, with an audit trail of the decision. Last write wins is acceptable only for fields where the loss is immaterial, and that should be decided field by field and written down.

Can staff reach CJIS data from a phone or tablet in the field?

Yes, provided the device, the application, and the people using it meet the CJIS Security Policy, which covers encryption, authentication, mobile device management, and screening for anyone with access, including vendor staff. The policy is revised periodically, and your state CJIS Systems Agency administers it for agencies in your state. Confirm the current requirements with them before design decisions are locked in.

Our agency is on FirstNet or has carrier priority service. Do we still need offline capability?

Priority and preemption help when a network is congested. They do not create coverage where none exists. Rural terrain, building interiors, basements, tunnels, and parking structures still produce dead zones, so field applications should be designed for intermittent connectivity whatever the carrier or network.

How do we get an internal app onto staff devices without publishing it publicly?

Both major mobile platforms support private distribution to enrolled devices through your mobile device management system, using organization developer accounts. Require that the agency hold those accounts and the signing credentials, so a change of vendor does not strand the application. A public-facing companion app still goes through normal store review and should be scoped separately.

Field & Mobile Applications