Plansmith
Fleet Management

Fleet Management Planner

Research-backed planner built from a 60-product census of fleet software across 120 official source pages — a vehicle register with real custody, not a map with a spreadsheet bolted to it.

v1.0.060 sources · frequency-ranked

The problem this kills

Ask a coding agent for "fleet management software" and you get a live map. It is the most photographed surface in the category, so it is the one the model has absorbed, and it demos beautifully: pins drift across a city, a sidebar lists vehicles, everything looks operational. Then someone tries to use it and discovers the app cannot answer the only questions a yard actually asks. Which van is roadworthy this morning. Who is driving it. What is overdue. What did it cost per mile last quarter.

The second failure is subtler and much more expensive. The agent builds thirteen tabs — Fuel, Costs, Parts, Geofences, Map, Dispatch — and every one of them is the same table with a different label. A fuel entry with no gallons. A cost with no amount. A geofence with no radius. A part with no quantity. The navigation implies a fleet system; the data model is one generic record wearing thirteen hats. We have watched exactly this happen in a controlled build-off, from a planner explicitly written to prevent it, which is why the failure mode is called out here rather than assumed away.

The third is that vehicles, drivers and work orders are modelled as independent lists. A defect found on a pre-trip does not become a work order. A completed repair does not return the vehicle to service. An open safety defect does not stop the same van being assigned again tomorrow. Each screen works; nothing connects; the operator goes back to the spreadsheet the software was bought to replace.

Why your agent cannot fake this

This planner is grounded in a 60-product census — a frozen cohort with 120 official source pages, one vote per product per capability, reconciled into 43 macro capability families, 8 dependency-valid lifecycle paths, 7 role and screen contracts and 16 usable visual references.

The cohort is stratified rather than scraped: general SMB fleet administration (Fleiko, CodeNekt, AUTOsist, Simply Fleet, FleetCheck, Odoo Fleet, FLEETMATE, Fleet Maintenance Pro), telematics-led operations (Samsara, Geotab, Verizon Connect, Azuga, Webfleet, Quartix, Cartrack, Cobli), maintenance and FMIS platforms (Fleetio, RTA Fleet360, AssetWorks FleetFocus, FASTER Web, Cetaris, FleetWave, M5 Fleet), and safety and compliance systems (Motive, Zonar, Lytx, Netradyne, Teletrac Navman, Microlise, Whip Around). Fifteen rejected, duplicate and adjacent rows are preserved rather than deleted, so the boundary is auditable.

That boundary is the part your agent cannot reconstruct, because it is defined by what disqualifies a product. The core object is the vehicle or powered asset. A product fails the vertical the moment a shipment, a customer job, a rental contract, a freight load, a passenger fare, a generic asset or integration plumbing becomes the organizing centre. That one rule is what stops "fleet management" drifting into logistics, field service, or asset tracking generally.

And the research refuses to let frequency alone decide scope. APIs and integrations are evidenced in 39 of 60 products and are still held back as a selected branch, because integration plumbing should never dominate a normal fleet product. Live GPS appears in 30 of 60 — common, not universal — so an inventory-and-maintenance product is allowed to be complete without pretending to offer live location. Driver licence and qualification appears in only 5 of 60 public evidence sets, yet becomes required substrate the moment driver eligibility or regulated operation is selected. Offline capture appears in 3 of 60 and therefore stays an explicit environment branch, never something inferred from the presence of a mobile app. Roles, scoping and audit are under-described in public marketing — 11 of 60 and 8 of 60 — and the standard requires them anyway for every non-public workflow.

The research is also explicit about its own limits. Capability counts mean proven in the reviewed official evidence, not an exhaustive claim that every non-voting product lacks the capability. One product (Odoo) was observed live and deeply; ten more used documented current workflow evidence; failed login, demo, TLS and bot-gated attempts are recorded as failures rather than quietly converted into observed behaviour. Per-jurisdiction compliance, map and telematics providers, fuel-card providers and offline behaviour are named as requiring discovery rather than assumed.

What you actually get

A planner that treats a vehicle as a custody record moving through a lifecycle, not a pin on a map:

  • The buyer-recognizable centre is fixed. Overview → Vehicles → Drivers → Inspections → Maintenance → Work Orders → Fuel → Reports. Governance, policy, audit-evidence and export-artifact pages are explicitly forbidden as primary navigation — they support the loop, they never replace it.
  • Readiness gates assignment. Onboard vehicle and driver → verify readiness → assign or dispatch → operate and monitor → record meters, fuel, defects, incidents, documents and costs → maintain or repair → verify and return to service → review utilization, risk, compliance and replacement. An open safety-critical defect has to be able to stop the next assignment.
  • Every workbench owns real fields. Fuel carries gallons, odometer and cost so consumption is computed rather than typed into a title. Costs carry an amount so cost-per-mile is derived from source rows. Parts carry quantities that reconcile across reserve, order, receive, issue and consume.
  • Depth is bounded and selected. Basic is a genuine register-to-maintenance lifecycle; Moderate adds availability, assignment, location, dispatch, history, cost and export depth; Advanced adds only explicitly chosen geofencing, parts, driver-behaviour, incident, compliance, integration, emissions or vendor branches. No depth silently selects every observed family.
  • The mobile surface is designed for the person holding a phone in a yard. The research includes a mechanic's complaint about inspection tools with excessive scrolling and controls; the planner answers it with dense single-task forms and fast numeric capture rather than a shrunken desktop table.

The planner emits a hot CLAUDE.md or AGENTS.md plus split spec files, with a custody gate that stops the agent scaffolding before the spec is written and locked.

Proven in a four-model build-off

This is the most tightly controlled dogfood we have run. Four working fleet systems were built from one byte-identical planner package — same source hash, same generator, same sixteen selected features — so every difference between the results is the model, not the brief. Fable 5 scored 98, GPT-5.6 Sol 93, Grok 4.6 78 and Gemini 3.7 Flash 72 under the same audit.

The spread is the interesting part, and it is published rather than smoothed over. The top two produced real domain models, working role separation and reproducible verification suites. The lower two are where the planner's own failure modes showed up in the wild: one shipped thirteen features as one generic record with no domain fields, and one left its first-run setup route completely unauthenticated while storing a hardcoded fuel-efficiency constant as though it had been measured. Both were caught by audit, and one of them was reworked and rescored afterwards. The full board is published as a PlanSmith benchmark.

The winning build runs as a live demo you can sign into from this page — a ten-vehicle service fleet with real status, assignment, inspection, defect, maintenance and fuel history behind it.

The inventory · 01

The frequency-ranked ledger.

Feature
Prevalence across 60 tabulated fleet products
Sources
Freq.
Fuel management and consumptionThe most evidenced capability in the category, and the one generic builds fake hardest — a fuel entry without gallons and an odometer reading cannot produce consumption at all.
41/60
68.3%
Dashboards, reports, and analyticsCore only when every figure drills to the source rows behind it. A tile that cannot be opened is decoration, not a report.
41/60
68.3%
Vehicle and asset inventoryThe product centre. The register has to open a real vehicle record carrying status, driver, inspection, maintenance and fuel history.
40/60
66.7%
Preventive maintenance schedulesIntervals in miles and days with a next-due that recomputes on completion — not a to-do list that never advances.
40/60
66.7%
APIs, webhooks, and external integrationsEvidenced in 39 of 60 and deliberately held back as a selected branch: integration plumbing must never become the organizing centre of a fleet product.
39/60
65%
Driver mobile app and field captureDense single-task forms and fast numeric capture. Drawn directly from a mechanic's complaint about inspection tools with excessive scrolling.
32/60
53.3%
Digital inspections and checklistsA failed checklist item has to raise a linked defect and take the vehicle out of service — the inspection is a gate, not a form submission.
31/60
51.7%
Expenses, cost per mile, and total cost of ownershipCost per mile must divide period spend by distance driven. Dividing by the sum of odometer readings is off by roughly two orders of magnitude — a real defect found in the build-off.
31/60
51.7%
Regulated compliance: ELD, HOS, IFTA, tachograph, DVIRSelected by jurisdiction rather than grouped behind a vague Compliance page. The research names per-jurisdiction rules as requiring discovery, not assumption.
31/60
51.7%
Live GPS map and vehicle locationCommon, not universal. An inventory-and-maintenance product is allowed to be complete without a map, and a map showing last-known position must say so rather than claim a live feed.
30/60
50%
Alerts, reminders, and exception queuesThe exception queue is where a fleet manager starts the day; it has to reconcile with the registers it links to rather than count a second store.
22/60
36.7%
Dispatch, jobs, routes, and field coordinationA job queue of who, where and when — kept distinct from the maintenance workbench, because practitioners report those needing different tools.
21/60
35%
Service and repair historyAppend-only history per vehicle is what turns repair-versus-retire from an opinion into a decision.
20/60
33.3%
Work orders and repair executionDocumented by under a third of the market despite being the mechanism that returns a vehicle to service. Raised on lifecycle dependency, not frequency.
18/60
30%
Defect, fault, and issue managementOnly 14 of 60 document it, yet nothing connects without it: the defect is the link between an inspection and a work order.
14/60
23.3%
Parts inventory and purchasingQuantities that reconcile across reserve, order, receive, issue, consume and return — a stock integer that only decrements is not inventory.
14/60
23.3%
Driver and operator recordsJust 13 of 60, because public marketing leads with vehicles. A vehicle without an accountable operator cannot support custody, inspection attribution or eligibility.
13/60
21.7%
Roles, permissions, and scoped accessUnder-described in public marketing at 11 of 60. Required anyway for every non-public workflow — a driver who can read the whole fleet is a defect regardless of what the market documents.
11/60
18.3%
Audit trail and append-only operating history8 of 60. Marketing pages do not sell it; a fleet arguing with an insurer needs it.
8/60
13.3%
Driver license, qualification, and eligibilityOnly 5 of 60 in reviewed evidence, yet it becomes required substrate the moment driver eligibility or regulated operation is selected.
5/60
8.3%
Offline or weak-connectivity capture3 of 60. The research refuses to infer it from the presence of a mobile app — it stays an explicit environment branch, because unproven offline sync is worse than none.
3/60
5%
See it in action · 02

Real apps this planner built.

Fleet register with real custody — live demoLive
Built by Claude Fable 5

Fleet register with real custody

“FleetOrbit” — a ten-vehicle service fleet from onboarding through inspection, defect, work order and fuel to cost per mile. Each unit carries status, availability, assigned driver, odometer, open defects and next service due, and the record opens onto its own history. The build scored 98 in the four-model build-off: roles are genuinely separate — the administrator is refused a screen the fleet manager owns, and a driver sees only their own assignment. Sign in at /login with dana@meridianfleet.example (fleet manager) or marcus@ (technician), rosa@ (driver), priya@ (administrator), password MeridianDemo!2026. You land on its public service-request page; sign in from there. Its one-click demo sign-in is switched off in production on purpose, so the credentials live here rather than on the page.

Open live demo
The same planner, twenty points lower — live demoLive
Built by Grok 4.6

The same planner, twenty points lower

“Harborline Fleet” — worth opening next to FleetOrbit, because the two were built from a byte-identical planner package. The foundation is strong: it is the only build of the four whose full 42-check suite re-runs cleanly from an empty database, and it ships a second company in its own data purely to prove customer separation. The product on top is thinner — thirteen of its sixteen workbenches are the same four-column table with different labels, so Fuel has no gallons and Costs has no amount. Its first audit also found three of the four roles unable to create anything; that was repaired and it was rescored 65 → 78. Demo buttons on /login sign you straight in as manager, driver, technician or administrator.

Open live demo
The one with the front door — live demoLive
Built by GPT-5.6 Sol

The one with the front door

“Roadstead Fleet” — the same planner again, and the only build of the four that refuses a stranger properly: every staff page redirects a visitor without a session to a sign-in screen, an address that does not exist returns a real not-found, and a cross-origin request to the login endpoint is rejected outright. Sign-in tokens and customer tracking links are both stored scrambled, so reading the database hands you neither. It arrives locked by default — this demo has its role buttons switched on deliberately, while the one-time owner claim stays off. You land on its public front door; sign in from there and pick a role.

Open live demo
The richest data model, after repair — live demoLive
Built by Gemini 3.7 Flash

The richest data model, after repair

“FleetFlow” — the fourth build from the same planner package, and the one that models a fleet most thoroughly: fuel with gallons, odometer and cost per fill, geofences with a radius, parts with reorder levels, purchase orders with vendors. It is also the only build that wires features to each other — a failed item on a pre-trip check raises a linked critical defect, takes the vehicle out of service, and a technician turns that defect into a work order and closes it out. It arrived unpublishable: the front end signed every visitor in as the fleet manager on page load, there was no sign-in screen at all, and its first-run setup accepted anonymous requests, so a stranger could rename the company. Those are closed — an anonymous request now gets 401 on every endpoint, including setup. It also used to write a fixed fuel-efficiency figure whenever it could not calculate one, under a heading that said “Calculated MPG”; a first fill-up now correctly reports nothing at all. Pick a role on the sign-in screen to get in.

Open live demo
Fleet Management Planner — PlanSmith