Five product areas. One reference they all answer to.

Nomad started as a proof of concept: could fleet operators see their data as something to act on, at all times, instead of numbers on a printout at month end? A proof of concept has a launch date. What it does not have is a plan for what comes after it works, when payment, fuel, routes, analysis and invoicing all want a screen of their own.

The system first

So the first thing we built was not a screen. It was a design system Nomad's team could build against directly: tokens, components and a prototyping skill for their AI-assisted workflow, so a new product area starts from the same reference instead of from a copy of the last one. That is the difference between a suite and five apps that happen to share a logo.

Action, not reports

The design principle across all of it stayed the same: take the data Nomad generates and give it back so it drives action. Not reports. Not exports. Interfaces that tell you what to do next.

By handover

By handover the suite spanned payment, fuel management, route optimisation, data analysis and invoicing, with a client portal on top, on web and mobile. Every area after the first was a release 1.1, not a rebuild: the system absorbed the change, and Nomad's team shipped it themselves. That is what we mean by a foundation that stays changeable. It is built to outlast the engagement, and it did.