Why This Project Exists

The direct trigger was a conversation with a facilities management company running 40+ engineers across commercial sites. They had a Timesheet Excel spreadsheet. Every Friday, engineers texted their hours to a coordinator who manually entered them. Mistakes were common. Checking whether someone had actually visited a site was impossible without asking the engineer directly.

The problem wasn’t unique to this client. It’s endemic in the UK trades and facilities management industry: distributed workforces, fragmented communication, no digital record of where people actually were throughout the day.

LabourWatch was built to solve this at a platform level, not just for one company.

The Core Challenge: Real-Time Presence Without Being Creepy

Workforce tracking software has a trust problem. When workers know they’re being tracked, productivity paradoxically drops — not because they suddenly become dishonest, but because the surveillance itself creates anxiety. Studies on electronic monitoring consistently show this effect.

The design brief for LabourWatch was specific: give managers visibility without creating a culture of surveillance. This led to two non-obvious architectural decisions.

No continuous GPS tracking — The system only captures a GPS location when the engineer checks in at a site. Between check-ins, location is not recorded. Managers can see that someone visited Site A at 09:42 and Site B at 11:15 — not a breadcrumb trail of their entire morning.

AI anomaly detection as the primary interface — Rather than presenting raw data and expecting managers to spot problems, the system highlights anomalies. An engineer whose average site visit drops from 45 minutes to 12 minutes. A team covering twice as many sites in a day as their historical average. These surface automatically; raw timesheets don’t.

The Technology Choices and Why

Next.js 16 with React 19 — The decision came down to the fact that this is a data-heavy application with complex state. Next.js handles the routing, API routes cover the server-side logic, and React 19’s concurrent features handle the real-time dashboard updates without manual memoisation overhead. For a team that needs to onboard junior developers, Next.js is also a readable stack. The alternative of a pure SPA would have created more complexity with less obvious benefit.

PostgreSQL with Prisma — The relational model was the right choice here. Engineers belong to teams, teams belong to clients, clients have sites, engineers clock in at sites. This is a structured relationship graph, not a document store problem. Prisma’s migration system also meant schema changes during development were straightforward, which matters when the client discovers mid-build that they also need to track certifications.

Redis for session management — The dashboard’s live updates use server-sent events (SSE). Redispub/sub handles the fan-out to connected clients. When any engineer clocks in, a single write to Redis propagates the update to every connected manager’s dashboard instantly. Without Redis, you’d either poll the database (expensive) or implement a multi-server broadcast mechanism (complex).

Mistral AI for anomaly detection — The anomaly detection layer runs on Mistral’s API. The model is given a rolling 30-day baseline per engineer and flagged when current behaviour deviates significantly. The key engineering decision here was to NOT use the raw anomaly score — instead, anomalies are bucketed into severity levels (info, warning, critical) and only critical anomalies trigger immediate manager notifications. This reduced false positive rates significantly compared to earlier versions that notified on every deviation.

The GDPR Dimension

Building a system that tracks people’s location and working hours for UK businesses means GDPR compliance isn’t optional — it’s the architecture.

The key decisions:

Consent capture at onboarding — Engineers don’t use the app until they’ve explicitly consented to location tracking at site check-in. This consent is stored in the database with a timestamp and version of the privacy notice they agreed to. The legal basis is legitimate interest, but only for the specific scope of site attendance verification, not general workforce surveillance.

Data minimisation — Location data stored is the check-in point, not a continuous GPS trace. Historical location data beyond 90 days is automatically deleted unless there’s an active dispute in the system.

Data export — Every engineer can request a full export of their tracked data at any time. This is handled by a background job that generates a PDF and emails it within 30 minutes.

Right to erasure — Deleting an engineer account triggers the full data erasure workflow. Timesheet records are retained for the statutory 7 years (legal obligation), but location records and biometric data are deleted immediately.

The Dashboard Design Problem

The hardest part of LabourWatch wasn’t the backend — it was the dashboard. Facility managers are not data analysts. They need to make quick decisions: is today’s schedule on track? Does anything need intervention?

The first version of the dashboard was a data-dense table view with sorting and filtering. It was technically comprehensive and practically useless. Nobody wanted to sit and scan rows of data at 7:30am before heading to site.

The redesign took a card-based approach: today’s jobs as cards with traffic-light status indicators, a map view for geographic planning, and a single alert panel for AI-detected anomalies. The data is the same; the presentation is fundamentally different.

The lesson: for operational tools used by non-technical people in time-pressured situations, display density is the enemy. Every piece of information that doesn’t need to be on screen right now should be one tap away.

Results

The pilot deployment covered 12 engineers across 3 facilities management contracts. After 3 months:

  • Timesheet submission time: reduced from 45 minutes (Friday afternoon manual entry) to under 5 minutes daily — engineers check in at each site, timesheets auto-populate
  • Site visit verification: 100% — every site visit is GPS-verified, no more “I was definitely there” discussions
  • AI anomaly alerts: ~8 per week across the fleet — of which roughly 60% are genuine issues (overruns, missed sites, incorrect job codes), 40% are explainable (client cancelled site last minute, traffic delays)
  • Manager time on workforce administration: reduced by approximately 2 hours per week per manager — largely from eliminating the Friday timesheet reconciliation process

What I’d Improve

The AI anomaly detection is functional but limited. It’s a statistical model operating on historical baselines, which means it struggles with seasonal variation (a surge in winter call-outs for heating breakdowns is normal, not anomalous) and genuinely novel situations. I’m exploring ways to incorporate client calendar data so the system can distinguish between expected variation and genuine anomalies.

The second area is mobile. The current mobile experience is a simplified view, not a full PWA. Engineers have asked for the ability to raise job completion notes directly from the site visit screen rather than waiting until the end of the day. That’s the next major feature.