How damage goes unrecorded
Ask most taxi or vehicle fleet operators how they track damage and the answer is a shared spreadsheet, updated when someone remembers, with the photographs somewhere in a WhatsApp group.
That is not a sign that nobody cares. It is what happens when reporting damage properly takes longer than ignoring it. A driver at the end of a shift, in a car park, in the rain, is not going to open a laptop. So the scrape goes unreported, the next driver inherits it, and by the time the car reaches a mechanic there is no telling which shift it came from.
The costs are familiar:
- Repairs paid by the operator that should have been attributed to someone
- No history per vehicle, so a car's condition is whatever the mechanic remembers
- No clear queue for the mechanic — reports arrive by message, photo or word of mouth
- No answer to the owner's question, which is which vehicles are costing the business money
Make the report take ten seconds
The design problem is not the dashboard. It is the driver's side of it, from a phone, with no patience for software.
In Curbed, every vehicle carries a QR sticker. A driver scans it, photographs the damage and submits. No login flow, no forms to hunt through, no app to install from a store. If reporting is quicker than not reporting, reports get made.
From a note to a piece of work
Once it is in, a damage report becomes something with an owner and a status rather than a message in a group chat:
- Four roles (owner, admin, mechanic, driver), so a mechanic sees a queue and an owner sees the business
- Assignment and a status lifecycle, so a report moves from raised to in progress to done and somebody owns it at each step
- Repair history per vehicle, so a car's condition is a record rather than a memory
- Live dashboard updates and push notifications, so the office does not refresh a spreadsheet to find out what changed
- CSV import and export at every boundary, because fleets already have their data somewhere and will want it back out
- A stats view for the question owners actually ask
It is multi-tenant from the first line of code: every record belongs to one operator and every query is scoped to it. Building that in later is one of the more expensive mistakes available, so we did not leave it for later.
Next on the list is vehicle custody — drivers checking a car in and out at handover, so damage can be pinned to the shift it appeared in, mechanics know the moment a car is back and free to work on, and a vehicle that is not roadworthy can be stopped from going out.
Where it is now
Curbed is live with a Dutch taxi operator. It is our own product, not client work: built, owned and run by BSquared, on the same stack we use everywhere else — Next.js, TypeScript and PostgreSQL, deployed with Docker.
The interface is in Dutch today. It was structured from the start so that adding a language is a translation job rather than a rebuild, which matters if you run a UK fleet and want to talk to us about it.
Product or bespoke
If the problem you have is the one above, meaning damage, repairs and accountability across a fleet, Curbed is the obvious answer, because it already exists. There is no point paying for a build of something that is already running.
If your fleet has a process Curbed does not cover, and that process is how you run the business, that is a different conversation. It may be a bespoke build, fixed price off a written scope, with the code in your name. Often it starts with whatever spreadsheet is doing the job at the moment, and replacing the spreadsheet is the first phase.
Either way, get in touch and tell us how damage and repairs are tracked on your fleet today.