Rotor — Management System for Repair Shops

The problem

A body shop runs on a set of overlapping records: which cars are in, what was quoted, what the insurer authorised, which parts are on order, what has been invoiced and what has actually been paid. Most shops of this size run that on one ageing program plus a constellation of spreadsheets, and the join between them is a person.

What I built

Rotor replaces the constellation: repair jobs, customers and their vehicles, active and passive invoicing, insurers and their assessors, estimates, and the reporting on top. It is used in a workshop, on a tablet, often with dirty hands — anything that costs more clicks than the old way gets abandoned, so the screens were designed against that and not against a demo.

The interesting work was the domain. A repair job is not linear: it can be waiting on an insurer while parts are already ordered, and delivered before it is invoiced. The model represents partial, out-of-order progress instead of collapsing into a status field that means something different in every shop. Importing years of legacy history was built as part of the product, because in practice it is never run once.

Where it stands

In production, running the daily operation of repair shops end to end, with the old history carried across rather than abandoned — and the switch happened without a day of downtime.