One custom system to replace a contractor's patchwork of field tools

The problem

The company runs crews across Connecticut on public road and bridge contracts. Its field operations ran on a custom app built in 2018 (separate Android, iOS and web versions), with three SaaS subscriptions layered on top to cover what it didn’t do: a geo-tagged clock-in app, a receipt-tracking app and a contract-management tool.

When I read through the old system, the problems went deeper than the interface:

Employee IDs had raw Social Security digits built into them, and the web portal stored full SSNs in plain text.
The “safety check performed” field on daily reports was hard-coded to true, whatever the foreman actually entered.
There was no approval workflow for hours on any platform, even though the original spec called for one. Rejections were written to a side table with no link back to the timecard they rejected.
License, medical-card and OSHA-card photos were stored inside the database as raw text.

What it was costing them: three subscriptions whose data didn’t connect to each other or to the legacy app, and real compliance exposure on employee data.

How I scoped it

I started from the code, not the sales proposal. I audited the legacy apps on all three platforms to separate what actually worked from what the original proposal said existed. Several specified features had never been built anywhere. That audit became one written scope document, which served as the source of truth for every later decision.

I put ownership before features. Phase 1 moved the code repository, domain, hosting and database into the company’s own name. That was a precondition: I wasn’t going to build on infrastructure the client didn’t control.

I prototyped the riskiest workflow first. Before committing to the full build, I made a working map prototype of crew clock-in and geofence editing, the part the field had to trust. I rolled it out to a night crew for live testing on the job before building the rest.

I scoped and rolled it out on site, working directly with the owner, the office staff and the field supervisors.

I made decisions around field conditions:

A progressive web app instead of native apps: nothing to install from an app store, and it keeps working offline, queuing entries until signal comes back.
Location is captured only at clock-in and clock-out, never tracked all day. That’s enough to verify a shift without draining batteries or tracking crews continuously.
One language (TypeScript) across the web app, the field app and the API, with shared types, so a small team can change a workflow end to end without drift.

Just as important was what I cut. Performance grading, GPS-based fraud alerts and injury flagging were removed from scope at the company’s call. In-app signatures are on hold until the company makes a product decision. Payroll integration with QuickBooks Online is designed to slot in later without a rebuild.

What I built

Two apps on one backend: a mobile-first field app for crews and a web portal for the office.

In the field, a worker:

picks their crew and clocks in, and the app checks their GPS location against that site’s geofence
splits the shift into labor-classification blocks (e.g. 4 hours concrete, 2 hours ironwork) that must add up exactly to the clocked time
files the daily site report, modeled on the state’s paper form
logs drive miles, fuel receipts and maintenance issues against a vehicle
submits credential renewals with a photo

In the office, staff get:

A timecard queue where nothing auto-approves. Late and out-of-zone punches are flagged automatically, and every approval, denial, edit and crew reassignment is kept in a full audit trail.
Credential tracking for licenses, medical cards and OSHA cards, with 30-day expiry warnings and a review step for renewals, plus a federal (FMCSA) driver-qualification file restricted to admins.
Purchases and receipts that can be split across several jobs or yard locations, with each split required to add up to the exact total.
Inventory as a log of stock in and stock out, never a quantity quietly overwritten.
Contracts, work orders, labor classifications with rates, and a statewide map of active crews.
An Excel hours report that handles night shifts crossing midnight correctly, including Sunday-night hours that roll into the next week.

Underneath, I fixed the legacy mistakes:

fresh IDs with no personal data in them
SSNs encrypted at rest and only ever shown as the last four digits
photos moved to object storage
five role tiers (admin, supervisor, inventory manager, foreman, laborer) enforced by the database itself and checked again by the API

People
- Field crews & foremenOn their phones, often with weak signal
- Office staffAdmins, supervisors, inventory manager
HTTPS · offline sync
Apps
- Field appPWA · service worker + IndexedDB
- Web adminNext.js on Vercel
REST API
Services
- Node/TypeScript APIApprovals, flags, exports
- Shared types packageOne schema across web, field and API
SQL · row-level security
Data & integrations
- Postgres on SupabaseFive role tiers in RLS · SSNs encrypted
- Object storageReceipts and credential photos
- Google Maps PlatformGeofences and the statewide crew map

Fig. Two apps, one API, one database. Role rules are enforced in the database, not just hidden in the UI.

Admin dashboard with counts of expiring credentials, hours pending review, low inventory and flagged clock-ins, above lists of sample employees — Fig. 1 · Sample data Office dashboard: what needs attention today

Timecard queue filtered to flagged entries, showing sample employees with late and outside-zone flags and their distance from the job site — Fig. 2 · Sample data Flagged timecards: late and out-of-zone punches surface automatically

Receipt detail for a sample crew purchase, with its cost split between a work order and a warehouse location — Fig. 3 · Sample data Crew purchase split across two cost centers

Result

Replaced three SaaS tools (a geo-tagged clock-in app, a receipt tracker and a contract-management tool) with one custom system the company owns
Runs the company’s daily operations on government and private jobs statewide
Being adopted company-wide, by every employee and crew
Every timecard reviewed before payroll, with late and out-of-zone punches flagged automatically
SSNs removed from employee IDs and encrypted at rest, and document photos moved out of the database
Strong reviews from across the company, from the principals to the office admins

Lessons

Scope the whole enterprise from the start, even when you build one piece. I scoped this project around field operations: time, credentials, fleet, purchases and inventory. Now the company has asked me to design a replacement for its bid-estimating and production-tracking software too. Some of the data structures I’d have shaped differently if I’d mapped those workflows on day one, since estimating, contracts and production all describe the same jobs. Next time I’d sketch the whole company’s data model before building the first module, even if only the first module gets built.