Mobile applications

Written for the basement, not the demo room

ASNPRO is used by elevator technicians, and a lot of elevator work happens in a machine room where there is no signal. That constraint shaped the whole app: everything a technician needs is on the device before they go down, and everything they enter survives until there is a network again.

Most field apps are written the other way round, assuming connectivity and adding a retry when it fails. That works in an office and falls apart in a basement, a warehouse or a rural site. We start from the failure case because that is the normal case.

Offline is an architecture, not a retry button

A record created without a network is written locally and queued. The technician carries on to the next job, the next form, more photographs. When the connection returns the queue drains in order, conflicts resolve by explicit rules rather than last-write-wins, and the user is told what synced and what did not.

What matters most is that the app never lies about state. A job shows as pending until the server has confirmed it. The alternative, a green tick that turns out to mean nothing, destroys trust in a field tool faster than any crash.

Camera, QR and location as evidence

In ASNPRO a maintenance visit cannot be closed without scanning the QR code on the equipment. It is a small rule with a large effect: it turns a report into evidence that somebody was physically at the machine. Photographs and a signature close the job, and both attach to the record instead of sitting in a phone gallery.

We build the same kind of flows for other field work, whether that is asset tags, delivery confirmation or inspection checklists, and we design them around what a person can do one-handed, with gloves on, in bad light.

One codebase, two stores

We build with Flutter, so Android and iOS come out of a single codebase. For the applications we take on, which are forms, lists, camera, maps, offline storage and background sync, that is the right trade: one team, one set of fixes, releases that do not drift apart between platforms.

Where a platform-specific capability is needed we write the native piece and bridge to it rather than abandoning the shared codebase. If a project genuinely needs fully native development we say so during scoping, not at month three.

From kickoff to store listing

First the field walk. We watch the job being done the way it is done today, on paper or in a phone gallery. Screens designed without that step are always designed for a desk.

Then a prototype on a real device. Flows are clicked through on a phone, in the conditions the app will be used in, before implementation starts.

Then the core loop end to end, with real authentication and a real backend, installed on the phones of two or three people who will actually use it.

Then the remaining modules in weekly builds, distributed through TestFlight and an internal Android track so feedback comes from usage rather than from screenshots.

Then store submission: listing text, screenshots, privacy declarations, permission justifications and the review cycle. We run that process; the developer accounts stay in your name.

The backend and the panel behind the app

A field app is only half the system. The other half is the panel where the office assigns work, sees what has come in and produces the reports. We build both, so the data model is designed once and the two sides cannot drift apart.

Push notifications, role-based access, exports and integration with whatever the office already runs belong to that layer, and they are designed in rather than bolted on.