DispatchGuard - Field Dispatch Reliability

DispatchGuard is a QA-first end-to-end case study for field operations. I built it around the failures that can quietly damage a dispatch workflow: concurrent assignments, stale offline work, licence rules, retries, and time-zone boundaries.

Completed v1.0 complete · v1.1 hardening verified Source code private · architecture and evidence shown here
  • TypeScript
  • PostgreSQL
  • Playwright
  • Offline sync
  • Concurrency
  • RCA / ADR
Back to selected projects Request a walkthrough

Server checks

185 / 185

Passing in the verified v1.1 test record.

Browser evidence

23 passed

Plus 72 intentionally skipped checks across five Playwright projects, each with a documented reason.

Decision record

6 ADRs · 4 RCAs

Architecture choices and reproduced failures remain traceable.

Deployment boundary

Tailnet only

The minimum runnable OCI deployment was verified privately, not presented as a public production service.

Why I built it

A normal happy-path demo can make dispatch software look simpler than it is. Two users can assign the same technician at nearly the same moment, while an offline device may later replay work based on stale state.

I treated those failure modes as the centre of the design. The project keeps the reproduction, design decision, fix, regression test, and RCA close enough that another reviewer can follow the reasoning without seeing the repository.

Key engineering and QA decisions

Protect the invariant in the database

Overlap protection is enforced where concurrent writes meet, rather than relying on a screen-level availability check that can become stale.

Make offline replay explicit

Idempotency keys, retry behaviour, and visible conflict outcomes keep a reconnect from silently duplicating or overwriting work.

Test the local calendar, not an idealised one

The suite covers New Zealand daylight-saving transitions alongside licence and assignment rules, where date and time assumptions often leak into business logic.

What I can walk through

The repository stays private, but the reviewable evidence is not reduced to a screenshot or a list of tools.

  • Failing-before and passing-after evidence for four concurrency-related defects
  • Architecture decision records for consistency, sync, and deployment choices
  • Root-cause records that connect symptom, reproduction, fix, and regression protection
  • Playwright results that separate executed checks from intentional skips, with a reason recorded for each skip

What this does not claim

These limits are part of the case study, not footnotes added after the fact.

  • The company, field data, and NZ electrical-services scenario are synthetic; this is not an EWRB or industry endorsement.
  • The recorded deployment is private and tailnet-only. There is no public production service or customer-use claim.
  • The session-auth implementation is suitable for the current case-study scope, not presented as production-grade identity infrastructure.
  • Playwright WebKit evidence is not a substitute for a completed physical-device Safari matrix.

Private code, reviewable work

I can provide a guided architecture, RCA, and test-evidence walkthrough for a genuine recruitment process without opening the repository publicly.

Request a walkthrough