Fleet overview and queue
Status filters, search, and a maintenance queue ordered by what is actually most overdue rather than by what was entered last.
Fleet maintenance scheduler demo
A fleet of 18 vehicles where every service task is due on mileage, on a date, or on whichever arrives first. Maintenance and dispatch share one vehicle registry, so a van in the workshop is a van dispatch cannot book.
Opens fleet.taiphamsolutions.com in a new tab. No account, no signup, and nothing you do in it leaves your browser.
What it does
The operations profile gets the fleet overview, status filters, search, a prioritised maintenance queue, and vehicle detail with the current odometer. The administrator profile gets vehicle creation and editing, interval editing with a preview of what it changes, archive and restore, warning settings, and an activity history.
The rule the whole app turns on is when a task is due. A date or a mileage reaching its limit makes the task due, and exceeding either limit makes it overdue. Acknowledging an alert does not reset anything, and neither does booking an appointment. Only a completed service moves the baseline, which is the distinction that stops a maintenance record from being wishful.
Dispatch sits beside it rather than in a separate world. Trip bookings, reassignment and holds all read the same vehicle registry, so a maintenance conflict is visible at the point of booking, and blocking on overdue work is a setting rather than an assumption.
Push a vehicle's odometer past a task's mileage limit, watch it move from due to overdue in the queue, then try to book it for a trip.
Features
18 vehicles, 72 service assignments, appointments, trip bookings and service history, seeded on first launch.
Intervals that mean something
Mileage, calendar days or months, or a combined trigger, with per-task due calculations and a preview when a plan is edited.
Workshop scheduling
Book, choose a workshop, reschedule, start, cancel, or complete partially, with service history and transactional updates behind every step.
Dispatch on the same registry
Trip bookings, reassignment, holds, maintenance conflicts, and configurable blocking on overdue vehicles.
The flow it closes, end to end
Every step below happens inside the demo. There is no point in it where the work leaves the browser and comes back.
A reading comes in
The current odometer is updated on the vehicle, which is the only thing that moves a mileage-based task towards its limit.
The task turns due, then overdue
Reaching a date or a mileage limit makes it due. Passing either makes it overdue, and the queue reorders around it.
The alert is raised and acknowledged
Acknowledgement is recorded against the alert and changes nothing about the service baseline, which is the point.
It is scheduled at a workshop
Book, reschedule or cancel. The appointment is a plan, not a completion, so the task stays overdue until the work is done.
The service is completed, fully or in part
Completion writes the history and recalculates the next due point from the reading at the time of service.
Dispatch sees the consequence
While the vehicle is held or blocked, a booking against it conflicts at the moment someone tries to make one.
What is real, and what is not
There is no server behind any of this, which decides both columns. The left one is what that constraint made worth building properly. The right one is what it rules out.
Actually handled
- Due and overdue calculated at month ends, across timezones, and on incomplete data
- Completion integrity when a service is only partly done
- Two tabs editing one vehicle, checked against a revision rather than last write wins
- English and Vietnamese across operations and administration
Deliberately not real
- Profiles demonstrate role-dependent behaviour. They are not secure authentication
- There are no background notifications and no synchronisation service. Nothing runs while the tab is shut
- The device clock is the time source, so a wrong clock produces wrong deadlines
- Each browser profile and origin holds its own data. Moving it means exporting a backup
How it is built
The write-up sells harder than the application does, so it is on the page rather than in a repository nobody can open.
- Stack
- Preact, Signals, TypeScript, Vite, and IndexedDB through idb. No application server, no remote database, no runtime asset from anywhere else.
- Budget
- The build reports raw, gzip and Brotli sizes and fails against a 1 MiB raw and 250 KiB gzip deployment budget.
- Concurrency
- Data loads with a database revision. An open form keeps the revision it was opened with and offers a reload when another tab has moved on, so a stale write is refused rather than applied.
- Tests
- Unit and integration tests over interval boundaries, month ends, timezone dates, incomplete data, completion integrity, dispatch restrictions, backup validation and concurrent edits, plus browser tests for completion, admin creation, both languages, backups and the mobile layout.
The services this is evidence for
A demo exists to prove something on the offer list rather than to be impressive on its own. These are the ones this one argues for.
The other demos
Each one is a different kind of problem, and all of them are in the Demos menu at the top of the page.
Want the version of this with your rules in it?
This one was built to a constraint nobody would choose. Yours would have a server, real accounts, and the parts of the domain that are actually hard. Tell us what the software has to do and we will tell you what it takes.
Bring the messy version of the problem. That is the conversation we enjoy most.