Crew and equipment scheduling: from discovery to production

Problem

A field-services business planned its crews, machines and hired transport across many work sites in a shared spreadsheet plus a separate crew app. The scheduling rules lived in one planner's head. Double-booked people and machines, machines scheduled at a new site without time to move there, and transport shortfalls were found on the day, and the long-term plan and the weekly plan drifted apart. It was not obvious whether to buy an off-the-shelf scheduling product or build something.

Goal

First, capture the real rules and make an evidence-based build-versus-buy decision the client could sign off. Then replace spreadsheet planning with one shared platform that catches conflicts as the plan is edited, keeps weekly work linked to master jobs and the long-term plan, and leaves every decision with the planner.

My role

I led discovery and solution design end to end: I ran and mined the requirement sessions, reconciled them with the client's real workbooks, researched and priced the alternatives, wrote the data model and scheduling specification, designed the access and sign-in model together with the client's IT provider, built the clickable wireframe, and wrote the QA and readiness packs. I was then the sole developer and architect of the platform (scheduling engine, API and storage layer, front end, sign-in, deployment, backups and CI) and ran the client check-ins that drove each change.

Solution

Discovery first, then a web platform built around a pure, fully tested scheduling engine. People, machines and transport are resources; jobs are dated operations. The engine checks every proposed change and returns warnings, suggestions and shifted schedules for the planner to confirm. Nothing is committed automatically.

How it works

Discovery.

Requirements come from recorded sessions cross-checked against the client's own schedule workbooks, so every rule has a source.

Candidate products (industry scheduling suites and resource-scheduling components) are compared on fit and cost against a custom build.

The chosen build is specified as a data model plus explicit rules covering resources, operations, equipment transfers and capacity.

Security is designed around single-tenant enterprise sign-in and read-only, app-only access to one cloud document library, reviewed with the client's outsourced IT provider.

A static clickable wireframe is validated with the planner before any code; readiness and QA packs map each requirement to acceptance checks, and dated audits compare what was asked for with what was built.

Platform.

The planner edits the week on a table, board or Gantt view. Before saving, the front end asks the engine to validate the proposed schedule.

The engine expands equipment groups into the machines they stand for (a group whose members are not yet known is treated as one indivisible unit, so it cannot escape the check), flags any person or machine in two places on one day, checks that each machine has time to move between sites, flags disallowed moves and out-of-service windows, and checks transport bookings for genuinely overlapping time windows. Transfer records are parsed into exact machine identifiers rather than matched as fragments of text.

Warnings are shown, never enforced: a confirmed override still saves.

Transport needs are suggested from each job's requirements, and a per-provider daily view shows each transport provider's commitments across jobs.

Moving or copying a job or a week carries its crew, machines and equipment transfers with it, under an explicit policy for what a copy keeps and clears. The weekday is always derived from the date, never from a stored label.

The API saves each record in a transaction behind one storage interface (managed PostgreSQL in production, SQLite locally), reconciles weekly rows to master jobs and the long-term plan, and derives job progress from work actually recorded.

Staff sign in through either of two enterprise identity providers, with tokens verified locally against published keys and role-based editing. The app reads a cloud project library read-only, shows a cached weather forecast that fails softly, handles photo uploads with checks, and round-trips CSV and spreadsheet files.

An idempotent deploy script targets serverless containers with a managed database, daily backups and point-in-time recovery; CI runs the test suite against a real PostgreSQL service plus browser end-to-end tests.

Technical challenges

Rules that existed only as habits in a spreadsheet had to be inferred from real data and then confirmed with the planner.

Keeping a traceability chain from each request to its test.

Designing least-privilege document access that an outside IT provider would accept.

Equipment groups recorded without members, and free-text transfers that broke naive matching in both directions.

Transport that needs a true time-overlap check rather than a same-day check, and copies that must bring the right transfers with them.

Strict parsing of human time formats, and date arithmetic that must ignore stale weekday labels.

Per-record saves with fresh ids, a pure engine that is fully unit-testable, two identity providers, and identical behaviour across two databases.

Capabilities

Requirements capture with provenance
Priced build-versus-buy analysis
Data model and scheduling specification
Least-privilege identity and document-access design
Interactive wireframing and QA traceability
Weekly, board, Gantt, long-term and job views
Crew and machine double-booking detection with group expansion
Machine-transfer timing, move-rule and maintenance-window checks
Transport overlap and provider commitment checks
Transport suggestions from job requirements
Suggest-and-confirm edits with overrides
Job and week move and copy with propagation
Job progress from recorded work
Dual enterprise sign-in and read-only cloud document access
Photo uploads and spreadsheet import and export
Backups and point-in-time recovery

Technology

Impact

The client got a documented, signed-off basis for building instead of buying, a security design accepted by its IT side and a test plan. It then got a live shared schedule that surfaces conflicts while the plan is being made rather than on the day, keeps the weekly and long-term plans linked, and leaves the planner in control, running in production with managed backups and automated tests. No metrics are claimed.

Skills demonstrated

Client discovery and business analysis
Vendor evaluation and build versus buy
Solution architecture
Security design with a third-party IT provider
UX wireframing
QA planning and traceability
Domain modelling
Constraint and conflict detection
Pure-function engine design and testing
Full-stack TypeScript without frameworks
Database abstraction across two engines
Enterprise identity integration
Cloud deployment, backups and CI
Turning client feedback into precise rules