techSync
An offline-first field app, a supervisor review portal, and a durable sync pipeline that lands approved jobs in a client's system of record — the record that triggers technician pay.
0+
jobs captured per week
0k
photos handled per month
0
technician & supervisor accounts
0
systems stitched together
Everything right of the dashed line sits inside the provider’s own tenant — no VPN, no shared network, no credentials of theirs on our side.
The problem
Around fifty technicians document cable-bearing work in places with no cell signal. Six photos and a set of meter readings per job. That paperwork is not admin — it is the thing that gets them paid. techSync captures it offline, routes it through supervisor review, and delivers it into the provider's system of record automatically, with a queue that will not drop a job.
Technicians work in areas with unreliable cell signal. Every "upload when you hit submit" tool on the market loses their work — and with it, the evidence they need to be paid.
Job assignments arrived as a spreadsheet attached to an email, a few times a day. Somebody re-keyed them by hand.
Approved work had to be re-entered a third time into the provider's system of record, field by field, photo by photo. Miss one and the technician's payment stalls.
Nobody could answer "where is job X right now?" without opening four different tools.
How it was built
- 01
Offline is the default, not the fallback
The technician app writes to on-device SQLite the instant a photo is taken or a reading is typed. The local database is the source of truth on the phone; the network is treated as an optimisation that may never arrive. Photos are compressed client-side and uploaded individually with retry and backoff when signal returns. Closing the app mid-job loses nothing.
- 02
Assignments arrive on their own
The provider's periodic job report is picked up automatically, parsed, tagged by service area, and screened for jobs that need a utility locate before anyone can dig. Those are surfaced to supervisors ranked by how close they are to their deadline. No re-keying, and nothing sits unnoticed.
- 03
Review is a queue, not an inbox
Supervisors get a thumbnail grid, full resolution on demand, and approve or reject with notes. Every job moves through an explicit state machine — draft, submitted, approved or rejected, synced or failed — so its position is never ambiguous.
- 04
Delivery is durable, never a direct call
Approval does not call the provider's API. It enqueues. A separate worker drains that queue, pulls the image bytes, assembles the package and delivers it idempotently, tracking status per photo. A failure retries. A retry cannot double-post. A stuck job is visible instead of silent.
- 05
Least privilege, enforced in the database
Row-level security means a technician can only ever read their own jobs — not because the UI hides the rest, but because the database refuses. Supervisors see the review queue. The delivery worker is the only thing holding a key that bypasses it.
The hard parts
Anyone can build the easy version. These are what the project was actually about.
No VPN. No virtual desktop. No exception.
The provider's security policy blocks the obvious integration routes, and their network is not ours to join. The delivery path had to be built out of the one channel their own policy treats as trusted — and validated end to end against the live system before a single job depended on it.
Payment-critical means idempotent
A duplicate delivery is as expensive as a missing one. Every write carries an idempotency key and per-item status, so a retry after a partial failure resumes rather than repeats.
A legacy portal with no API
One required step exists only as a web page a human clicks through. It is driven headlessly by browser automation, on a schedule, with screenshot capture on failure so a broken run leaves evidence instead of a shrug.
What it looks like
The real product interface, shown with made-up data.
Where it landed
- Job data goes in once, on the phone, in the field — and never gets typed again.
- Approved work reaches the provider's system of record without a human touching it, with all twenty data fields and the photo set intact.
- Delivery failures surface as alerts with a re-trigger button, instead of as a technician asking why they were not paid.
- The whole pipeline runs on roughly the cost of a phone plan per month.
Built with
Mobile
Backend
Web
Pipeline
Your turn
Got a process this shape?
Thirty minutes is usually enough to tell whether it’s worth building.
Tell me the thing your team retypes every week.
Thirty minutes, no pitch. I’ll tell you whether it’s worth automating, roughly what it would cost, and if the honest answer is “don’t bother” — you’ll hear that too.
hello@clearpathflow.io · Raleigh-Durham, NC