File Service Portal for B&R Chiptuning

At its core, B&R Chiptuning’s portal is a digital tuning file service: a dealer uploads a vehicle’s ECU file and receives a modified file in return. That one sentence describes the product completely — and explains nothing about the system it has become.

Because around this workflow, a business system has grown over the years: a dealer portal with sub-dealers and individual terms, credit accounts instead of a shopping cart, multiple payment methods, matching against the existing file library, an embeddable vehicle and pricing database, invoices, tickets, logging. Each of these extensions went into a system that was already running.

Batunet took over the portal in 2017. The application was already running on Laravel 5.1; in the same year, it was moved onto a new Laravel foundation and the business logic was moved into its own layer. Since then, the task was never to build the right thing once. It was to keep the portal evolvable over years — functionally and technically at the same time.

A file can reach the portal in two ways, and the two are deliberately kept separate. The file check is a search: it checks whether a matching file already exists in the library. The file service is an order: the dealer uploads the original file with vehicle data, requested performance stage and the flash tool used; the team processes it and returns the finished file.

What matters here is what doesn’t happen. The system doesn’t read the uploaded ECU file, doesn’t identify a vehicle and doesn’t guess anything. The file check computes a checksum and compares it with the checksums of the library in object storage — it either finds an identical file or it doesn’t. Neither AI nor content analysis is involved, and that is intentional: a method that guesses would be the wrong method in a workflow that ends with a charge.

The library itself grows through administration. It uploads tuning files in chunks so that large files don’t fail on a timeout; storage is in object storage, not on the application server.

Billing isn’t per order but via credits. That sounds simpler than a shopping cart, and it isn’t: there are several credit accounts side by side, including subscription credits that expire after thirty days. When a modified file is billed, a subscription credit is used first and only then regular credit.

Every booking is created as a transaction inside a database transaction with a row lock. Beneath the balance there is a transaction history, and two simultaneous operations can’t spend the same credit.

Top-ups are made via PayPal and Sofortüberweisung, at times also via Klarna — payment methods each with their own flows, their own callbacks and their own failure cases. After payment, the invoice record with a sequential number is created automatically; the PDF invoice is generated from it, including the notes for customers inside and outside the EU. In a system like this, a payment method added later is never just an integration: it has to fit into booking logic that already exists.

A framework ages faster than the business that runs on it. When we took over in 2017, the portal ran on Laravel 5.1, and in the same year it was rebuilt on Laravel 5.4. Laravel 5.8 followed in 2019, and in 2025 the jump to Laravel 10 with PHP 8.1 — the versions in between were skipped, and the migrations were regenerated from the existing database schema.

That is the real point of this case. A rewrite is tempting because it gets rid of the past. But in doing so, it throws away exactly the business logic that has evolved over years: pricing rules, role logic, status flows, edge cases that nobody can fully describe anymore because they are written down nowhere except in the code. If you want to keep that logic, you have to move the technical foundation beneath it while it is in production.

That is exactly what happened here: the business logic has stayed and kept growing — sub-dealer subscriptions, prioritization, subscription credits, additional payment methods — while the technical foundation was renewed several times. What makes software long-lived isn’t that it is never touched. It’s that it can be touched.