Fleet Management System

Problem

Staff in sales and administration at an energy services company took cars out daily, across several offices — mostly company vehicles, sometimes their own. Every record that mattered lived in a spreadsheet: who took which vehicle and when it came back, refuelling, filter and element changes, the condition of each one. The records existed without being dependable. Alcohol checks carried a legal retention period the spreadsheets were not really meeting.

The harder problem was that the client could not say what they wanted. They knew the spreadsheets were failing them and roughly which records mattered, but not what the software should be. A conventional requirements phase would have produced a specification neither side was equipped to evaluate.

That constraint shaped the approach more than the domain did.

Approach

Since the requirements could not be written down in advance, they had to be discovered by building. The client needed to see something running to know whether it was what they meant, which put a premium on how quickly a working version of an idea could be put in front of them.

I built it alone, through an agent workflow I had already developed on my own project template. Six specialised agents — architect, design reviewer, developer, tester, reviewer, package researcher — each with a narrow remit, dispatched one task at a time.

What made it fast was recognising where the constraint actually sat. Code output was never the bottleneck; my own design time was. So rather than tune the agents for speed I did the opposite, making them deliberately thorough, token-heavy and slow to start, then running several sessions in parallel so their latency overlapped with the work only I could do. While one session implemented a module and its tests, I was designing the next.

What made that parallelism safe was mapping module dependencies during the overall architecture pass, before any detailed design began. Vehicle inspections, insurance and maintenance all hung off the vehicle master and nothing else, so they could proceed independently. Dispatch, fuel and the alerting layer had to follow in order. Knowing which modules could not collide was what allowed sessions to run at the same time without merge conflicts.

The whole thing runs as a single Cloudflare Worker. Static assets and the API come from the same deployment, with requests under /api handed to the Worker and everything else served as files, so there is no separate frontend host to keep in step. Postgres sits on Supabase, reached through Hyperdrive because a Worker cannot hold a connection pool of its own. The driver app is an Expo build shipped through EAS.

Deployment is gated rather than immediate. A push to main runs typechecks, lint and tests; only then do migrations run; only then does the Worker deploy. Deploys queue instead of cancelling each other, since interrupting a run that is midway through a migration is worse than waiting. That pipeline mattered more than it would on a team — when one person is directing several sessions at once, the thing that catches a bad merge is not going to be a colleague.

The base of the system was working in about four days. The remaining three and a half months went into the domain: nine modules, twenty-two design documents, and the iterations that come from putting something real in front of a client who is still working out what they want.

Trade-offs

The workflow that made this fast is also the part I would not hand to someone else as it stands.

Over-engineering the agents was a deliberate response to two facts: sessions ran in parallel, and I was not going to read every line they produced. Defensive design was the substitute for a review I could not personally perform. It worked, but it stayed sensitive to how I broke the work down — get the task granularity wrong and both throughput and accuracy fell away. Which means the result rested on judgement I had accumulated rather than on the process itself. It is not a reproducible workflow. It is a workflow I can run.

The number of agents was the hardest call and I never resolved it cleanly. More agents buys cleaner context isolation and simpler individual tasks, both of which improve what comes back. It also buys more handoffs, and every handoff is somewhere a load-bearing detail can quietly fail to cross. I placed that line by feel and kept adjusting it.

The ground also moved while I was standing on it. When I designed the setup, context isolation was clearly worth its cost. Over the following months the models shifted toward completing more inside a single agent, which eroded part of the advantage a team of narrow specialists had. A workflow tuned to the characteristics of one model generation has an expiry date on it, and I was inside that window for the length of the project.

A smaller and more ordinary trade-off sat in the domain. I wanted administrators to own vehicle inspection records outright: a wrong entry there causes real problems, and a single owner is easier to keep accurate. The client came back and said entering every vehicle's inspection centrally was more work than they could absorb. So drivers submit and administrators approve. The approval step keeps a check on accuracy while moving data entry to the people already holding the document. I gave up the cleaner ownership model for a workflow they would actually use.

My scope

I was the whole team: architecture, detailed design, the client relationship, implementation and delivery, over three and a half months.

The division of labour inside that is worth being precise about. The agents wrote code, ran tests and reviewed. I decided what to build, in what order, and whether what came back was right. Every one of the 570 commits is mine in the sense that I directed and accepted it; very little of it is mine in the sense of having been typed by hand. Both halves of that sentence matter when judging what the work demonstrates.

I worked across the whole stack — a React and Vite administrative frontend, a Hono backend on Cloudflare Workers with Drizzle, and an Expo application for drivers — with the weight falling on the frontend, where most of the domain surface lives.

Outcome

The system was delivered and is in use. The spreadsheets it replaced are gone.

It came in well below what a conventional build of the same scope would have cost, which mattered more to the client than any technical property of it, and led to further work.

There is now interest in making it multi-tenant and selling it to other customers. That is where the trade-off above stops being abstract: the workflow that made this cheap to build is one I can run and have not yet made transferable, so productising it waits on handing maintenance and new features to someone else. The constraint on this project's future is not the software. It is that I built it in a way only I can currently continue.