Assign the job
The owner creates or assigns the service work; technicians see only the work assigned to their individual account.
← All case studies
Field service · Active build
From field visit to an approved, billing-ready record.
I am building a phone-first reporting system that gives technicians one clear closeout workflow and gives the owner a reliable review, correction, approval, and report trail. The goal is less chasing after the work is finished—and a record the office can actually use.
See how the system works ↓Independent illustration · synthetic record
9:41R0•••
Assigned today
Service visit 0042
✓Work performedComplete
✓Labour & crewComplete
✓MaterialsComplete
4Photos & receiptsRequired
Save draft
Owner review
One correction requested
Original field entry remains visible while the technician adds the missing record.
Return for correctionApprove report
Public-safe representationNo client data, screens, records, or proprietary source.
StatusPrivate pilot preparation
RoleProduct lead + builder
ScopeField entry through approval
OutputImmutable service report
01 The operational problem
The field work was complete, but the operational record was still scattered.
Hours, work performed, materials, receipts, photos, kilometres, and completion status could arrive through different channels and at different times. Missing details then had to be reconstructed before the job could move forward.
The system needed to make completeness easy for technicians without turning the form into paperwork theatre. It also needed drafts, deterministic submission rules, owner review, specific correction requests, return-visit history, immutable approved reports, and a clear billing-ready handoff.
02 The system
One traceable record from assignment through approval.
The workflow separates partial work from submitted evidence, preserves every material revision, and keeps approval authority on the server—not in the phone or browser.
Save a partial draft
The technician records progress on a phone without being forced to invent missing information or submit an incomplete closeout.
Complete the visit record
Capture labour, work performed, materials, attachments, visit outcome, and reviewed kilometres in structured sections.
Validate and submit
Deterministic rules identify missing required information; a valid submission becomes an immutable revision with an idempotent receipt.
Review or return
The owner approves the record or requests a specific correction while the original technician entry and prior visit history remain visible.
Generate the handoff
Approval binds a consistent service-report revision and creates a billing-ready operational handoff for later connected systems.
03 What I built
Product thinking, engineering, and operational controls in one delivery.
Workflow and state design
Defined the job, visit, draft, submission, correction, resubmission, approval, return-visit, report, and billing-ready states around the real field-to-office handoff.
Workflow designState modelField service
Secure application core
Built the versioned API, persistence boundary, server-owned authorization rules, audit trail, idempotent submission, immutable receipts, and report lifecycle.
FastAPIPostgreSQLAuditability
Phone-first experience
Built the assigned-jobs shell, job orientation, structured closeout sections, protected drafts, correction flow, accessible layouts, and tested session states.
Mobile webAccessibilityDraft protection
Mobile pilot packaging
Built hardened Android and iOS pilot shells around the tested web core with exact-origin controls, privacy covers, lifecycle handling, and synthetic acceptance tooling.
AndroidiOSPrivacy controls
04 Current stage
The core is built locally; private field acceptance is the next proof.
The durable workflow, phone-first web experience, correction and approval lifecycle, report generation, and mobile pilot shells have been built and exercised with synthetic records. The project remains in active delivery; production activation and real-data use are separate approval gates.
- 01Core job, visit, draft, submission, correction, approval, and report lifecycle implemented.
- 02Phone, tablet, and desktop workflows tested with synthetic identities and records.
- 03Android and iOS pilot packages built with restricted origin, lifecycle, and privacy behaviour.
- 04Private field acceptance, production activation, and any live integrations remain in progress.
05 Public boundary
Specific about the work. Careful with the client.
Included
The field-to-office problem, the controlled workflow, my product and engineering role, implemented system boundaries, verified synthetic testing, current delivery stage, and an independent illustration.
Excluded
Client identity, technician or customer records, photos, receipts, locations, production screenshots, credentials, private integrations, source code, internal metrics, commercial terms, and acceptance claims.
R0
06 Start with the workflow
Have an operational process that still depends on chasing, re-entry, and individual memory?
Routine Zero can map the work, identify the real control points, and build the smallest dependable improvement around it.
Tell me about one workflow →