Fleet Management Planner

The problem

Ask a coding agent for "fleet management software" and you get a live map. It is the most photographed screen in the category, so it is the one the model has learned, and it demos well: pins move across a city, a sidebar lists vehicles, everything looks operational. Then someone tries to use it and finds the app cannot answer the questions a yard 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 harder to see and costs much more. The agent builds thirteen tabs (Fuel, Costs, Parts, Geofences, Map, Dispatch and more), 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 suggests a fleet system, but the data model is one generic record used thirteen times. We watched this happen in a controlled build-off, from a planner written to prevent it. That is why this failure is named here and not assumed away.

The third failure 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 from being assigned again tomorrow. Each screen works and nothing connects, so the operator goes back to the spreadsheet the software was bought to replace.

What it is built from

The planner is based on a count of 60 products: a frozen cohort with 120 official source pages and one vote per product per capability. The count is organized into 43 macro capability families, 8 dependency-valid lifecycle paths, 7 role and screen contracts and 16 usable visual references.

The cohort was chosen in groups. It was not 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.
• Safety and compliance systems: Motive, Zonar, Lytx, Netradyne, Teletrac Navman, Microlise, Whip Around.

Fifteen rejected, duplicate and adjacent rows are kept in the record, so the edge of the cohort can be audited.

Your agent cannot rebuild that edge, because it is defined by what disqualifies a product. The core object is the vehicle or powered asset. A product falls outside this market as soon as a shipment, a customer job, a rental contract, a freight load, a passenger fare, a generic asset or integration plumbing becomes the centre of the product. That one rule stops "fleet management" from drifting into logistics, field service or asset tracking in general.

The research does not let frequency alone decide scope:

• APIs and integrations have evidence in 39 of 60 products and are still held back as a branch you select, because integration plumbing should never dominate a normal fleet product.
• Live GPS appears in 30 of 60. It is common but far from universal, so an inventory-and-maintenance product may be complete without pretending to offer live location.
• Driver licence and qualification appears in only 5 of 60 public evidence sets. It still becomes a required base as soon as driver eligibility or regulated operation is selected.
• Offline capture appears in 3 of 60, so it stays a separate environment branch. It is never assumed because a mobile app exists.
• Roles, scoping and audit are rarely described in public marketing (11 of 60 and 8 of 60). The standard requires them anyway for every non-public workflow.

The research is also open about its own limits. A capability count means proven in the reviewed official evidence. It does not claim that every other product lacks the capability. One product (Odoo) was observed live and in depth. Ten more used documented evidence of current workflows. Failed login, demo, TLS and bot-gated attempts are recorded as failures and were never turned into observed behaviour. Compliance per jurisdiction, map and telematics providers, fuel-card providers and offline behaviour are named as things that need discovery. None of them is assumed.

What you get

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

• The centre a buyer recognizes is fixed. Overview → Vehicles → Drivers → Inspections → Maintenance → Work Orders → Fuel → Reports. Governance, policy, audit-evidence and export-artifact pages are forbidden as main navigation. They support the loop and never replace it.
• Readiness controls 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 must be able to stop the next assignment.
• Every workbench has real fields. Fuel carries gallons, odometer and cost, so consumption is calculated and never typed into a title. Costs carry an amount, so cost-per-mile comes from source rows. Parts carry quantities that match across reserve, order, receive, issue and consume.
• Depth has limits and is selected. Basic is a real register-to-maintenance lifecycle. Moderate adds availability, assignment, location, dispatch, history, cost and export depth. Advanced adds only the geofencing, parts, driver-behaviour, incident, compliance, integration, emissions or vendor branches you chose. No depth quietly selects every observed family.
• The mobile screens are designed for a person holding a phone in a yard. The research includes a mechanic's complaint about inspection tools with too much scrolling and too many controls. The planner answers it with dense single-task forms and fast number entry. It does not shrink a desktop table.

The planner produces a main CLAUDE.md or AGENTS.md and separate spec files. A custody check stops the agent from writing code before the spec is written and locked.

Tested in a build-off

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

The spread is the interesting part, and it is published as it is. The top two produced real domain models, working role separation and verification suites that can be re-run. The lower two showed the planner's own named failures in real builds. One shipped thirteen features as one generic record with no domain fields. The other left its first-run setup route completely unauthenticated, and stored a hardcoded fuel-efficiency constant as though it had been measured. The audit caught both, 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.