How it works

Everything starts with a complete, untouched read of the ECU. Your tool — master or slave — produces it over OBD or on the bench depending on the reference, and it is that route which decides the rest, not the make of the vehicle. Always keep a copy of the original before any writing: it is your only way back if the vehicle has to return to its factory configuration.

A partial read, a file already modified by another workshop, or an export in a format the tool will not read back forces us to come back to you — and that is exactly what stretches a turnaround. Two minutes of checking before sending beats a round trip.

On arrival, the job is opened by an engineer, not by an automated system. They identify the exact reference, check that the read is usable and that the requested options are feasible on that ECU, then open the project. If something blocks — incomplete read, option impossible on that reference — you are told before your tokens are committed.

Calibration then happens on that particular vehicle's file: the maps concerned, the limiters, the associated monitors, checksum correction, a final review. The file comes back into your job with the engineer's remarks where there are any. Tokens are debited at that point, at the public price list: there is no last-minute surcharge.

Write the file with the same tool and by the same route as the read, with the battery on a charger: most writing incidents come from a voltage that drops mid-flash. Then check the cold start, the behaviour under load, the absence of fault codes, and take a road test before handing the vehicle back.

Something to adjust? The job stays open. You answer the engineer who handled it inside the portal, with what you observe — logs help a great deal — and the calibration is adjusted: revisions are free. Your original read stays archived with the project, which makes later work on the same vehicle markedly faster.