Garage and vehicle management
Service requests raised, categorised, worked and closed — against vehicles rather than against customers, with the parts, the labour and the history attached to each one.
Talk about scopeThe hard part is the bay, not the database
Recording a repair is straightforward. What is not is that a bay is occupied for as long as the job takes, the job cannot finish until a part arrives, the part has a lead time nobody controls, and a customer is asking today whether the car is ready. Every scheduling decision in a workshop is made against those four facts at once, which is why a system built as a list of jobs gets replaced by a whiteboard — the whiteboard shows the constraint and the list does not.
What we would build
A job that changes hands three times
A service request is opened at a counter, worked at a bay, and closed by someone who was not there when it opened. The record has to carry that handover: what was authorised, what was quoted, what was actually done, and what changed mid-job once the vehicle was open. Systems that model a job as a single row get abandoned for a whiteboard within a month, because the whiteboard at least shows who is waiting.
History belongs to the vehicle, not the customer
Vehicles are sold; customers change cars. If the service record hangs off the account, it fragments the first time either happens. Attach every job to the vehicle instead and a registration number alone answers what was fitted, when it was last serviced and what failed the time before — years later, to somebody who has never seen the file.
Stock a job has claimed but not yet used
Parts reserved against an open job are neither on the shelf nor consumed, and a system that tracks only those two states will sell the same alternator twice in one morning. The reservation is the part worth building carefully: it has to survive a job being paused for a week waiting on a supplier, and release itself when the job is cancelled rather than quietly holding stock nobody can find.
The trail you only want during a dispute
Who changed a price, who approved the discount, who reopened a closed job. This is the same audit spine every system we build carries, because it is never the feature anyone asks for while scoping and always the one they ask for the first time a customer disagrees about an invoice.
When not to build this
A packaged product is the right answer more often than a development company usually admits, and if your problem is an ordinary one that something off the shelf already solves, we will tell you so rather than quote for it. What follows is the case for the other answer — the conditions under which building is worth what it costs.
The workaround has become the process
A packaged system that mostly fits leaves a residue — the spreadsheet kept alongside it, the step done by hand every month, the field used to mean something it was not named for. When that residue is where the actual work happens, you are already maintaining custom software, just without any of the benefits of having built it.
The thing you do differently is the thing it cannot do
Every business has a few processes that are genuinely its own, and those are usually the ones it competes on. Off-the-shelf software is built for the average of a sector, so it handles the ordinary parts well and the distinctive part not at all. Building is worth it exactly where that overlap fails, and rarely anywhere else.
A vulnerability shared by every deployment
A vulnerability in a packaged product is a vulnerability in every deployment of it, and attackers only have to find it once. A system built for one business is not on that list.