Technician App

An end-to-end app for tracking technicians and managing field operations (installation, replacement and rectification jobs), built end to end.

Installation, replacement and rectification are three different jobs wearing the same uniform. Each has its own preconditions, its own proof-of-completion, and its own way of going wrong once someone is standing at a vehicle with a phone in one hand.

Field technicians and the operations staff who dispatch and verify their work.

Three job types (installation, replacement, rectification) were being coordinated through the same channels with no shared definition of 'done'. The first work was writing down, per job type, what has to be true before a technician starts, what proof closes it, and where each one usually stalls.

Coordination lived in messages and spreadsheets. Nobody could answer where a job stood without asking a person.

If the app carries job state as its primary object, rather than the technician or the vehicle, then dispatch, the technician and verification are looking at the same thing, and the coordination that lived in messages disappears because it has nowhere left to live.

Ship the field side first, because that is where the data is created; the operations dashboard is only as good as what technicians actually record. Keep the three job types on one flow with per-type steps rather than three apps that drift apart.

Preconditions and proof-of-completion before anything else. Offline tolerance before polish. Reporting last, because a report on unreliable data is worse than no report.

Designed for one hand, poor signal and bright daylight. Job state is the first thing on screen, not the last.

Large targets, one primary action per screen, and status you can read from arm's length. Every screen answers 'what is the next thing I do' before it answers anything else.

Angular and Ionic for a single cross-platform build against the existing platform APIs.

In progress. Ali owns frontend implementation, UI/UX, the PRD, and coordination across the teams involved.

In progress; nothing measured yet, so nothing claimed. What gets measured on the next release: time per job from installation to close, the error rate on job state changes, and technician adoption across regions.

Writing the PRD for a field product means interviewing for the exceptions, not the happy path. The happy path is the same everywhere; the exceptions are the product.