Fileservice-Portal für B&R Chiptuning

Im Kern ist das Portal von B&R Chiptuning ein digitaler Tuningfile-Service: Ein Händler lädt die Steuergerätedatei eines Fahrzeugs hoch und erhält eine bearbeitete Datei zurück. Dieser eine Satz beschreibt das Produkt vollständig — und erklärt nichts an dem System, das daraus geworden ist.

Denn um diesen Ablauf herum ist über die Jahre ein Geschäftssystem gewachsen: ein Händlerportal mit Unterhändlern und eigenen Konditionen, Guthabenkonten statt eines Warenkorbs, mehrere Zahlungswege, ein Abgleich gegen den vorhandenen Dateibestand, eine einbettbare Fahrzeug- und Preisdatenbank, Rechnungen, Tickets, Protokollierung. Jede dieser Erweiterungen kam in ein System, das bereits lief.

Batunet hat das Portal 2017 übernommen. Die Anwendung bestand bereits auf Laravel 5.1; noch im selben Jahr wurde sie auf eine neue Laravel-Basis gestellt und die Fachlogik in eine eigene Schicht überführt. Seitdem war die Aufgabe nie, das Richtige einmal zu bauen. Sie war, das Portal über Jahre entwicklungsfähig zu halten — fachlich und technisch zugleich.

Eine Datei kann das Portal auf zwei Wegen erreichen, und beide sind bewusst getrennt. Der Filecheck ist eine Suche: Er prüft, ob es eine passende Datei im vorhandenen Bestand bereits gibt. Der Fileservice ist ein Auftrag: Der Händler lädt die Originaldatei mit Fahrzeugdaten, gewünschter Leistungsstufe und verwendetem Flash-Tool hoch, das Team bearbeitet sie und liefert die fertige Datei zurück.

Wichtig ist dabei, was nicht passiert. Das System liest die hochgeladene Steuergerätedatei nicht aus, erkennt kein Fahrzeug und errät nichts. Der Filecheck bildet eine Prüfsumme und vergleicht sie mit den Prüfsummen des Bestands im Objektspeicher — er findet eine identische Datei oder er findet keine. Weder KI noch Inhaltsanalyse sind daran beteiligt, und das ist Absicht: Ein Verfahren, das rät, wäre in einem Ablauf, an dessen Ende eine Abbuchung steht, das falsche Verfahren.

Der Bestand selbst wächst über die Verwaltung. Sie lädt Tuningfiles in Teilstücken hoch, damit große Dateien nicht an einer Zeitüberschreitung scheitern; abgelegt wird im Objektspeicher, nicht auf dem Anwendungsserver.

Abgerechnet wird nicht pro Bestellung, sondern über Guthaben. Das klingt einfacher als ein Warenkorb und ist es nicht: Es gibt mehrere Guthabenkonten nebeneinander, darunter Abo-Credits, die nach dreißig Tagen verfallen. Wird eine bearbeitete Datei abgerechnet, wird zuerst ein Abo-Credit verbraucht und erst dann reguläres Guthaben.

Jede Buchung entsteht als Transaktion innerhalb einer Datenbanktransaktion mit Zeilensperre. Unter dem Kontostand liegt damit eine Transaktionshistorie, und zwei gleichzeitige Vorgänge können nicht dasselbe Guthaben verbrauchen.

Aufgeladen wird über PayPal und Sofortüberweisung, zeitweise auch über Klarna — Zahlungswege mit jeweils eigenen Abläufen, eigenen Rückmeldungen und eigenen Fehlerfällen. Nach der Zahlung wird der Rechnungsdatensatz mit fortlaufender Nummer automatisch angelegt; die PDF-Rechnung entsteht daraus, einschließlich der Hinweise für Kunden innerhalb und außerhalb der EU. Ein Zahlungsweg, der später dazukommt, ist in einem solchen System nie nur eine Integration: Er muss sich in eine Buchungslogik einfügen, die schon da ist.

Ein Framework altert schneller als das Geschäft, das darauf läuft. Das Portal lief bei der Übernahme 2017 auf Laravel 5.1 und wurde noch im selben Jahr auf Laravel 5.4 neu aufgesetzt. 2019 folgte Laravel 5.8, 2025 der Sprung auf Laravel 10 mit PHP 8.1 — die Versionen dazwischen wurden übersprungen, die Migrationen aus dem bestehenden Datenbankschema neu erzeugt.

Das ist der eigentliche Punkt dieses Falls. Ein Rewrite ist verlockend, weil er die Vergangenheit loswird. Er wirft dabei aber genau die Geschäftslogik weg, die über Jahre entstanden ist: Preisregeln, Rollenlogik, Statusverläufe, Sonderfälle, die niemand mehr vollständig beschreiben kann, weil sie nirgends stehen außer im Code. Wer diese Logik behalten will, muss die technische Basis unter ihr bewegen, während sie in Betrieb ist.

Genau das ist hier passiert: Die Fachlogik ist geblieben und weiter gewachsen — Unterhändler-Abos, Priorisierung, Abo-Credits, weitere Zahlungswege —, die technische Grundlage wurde mehrfach erneuert. Was Software langlebig macht, ist nicht, dass sie nie angefasst wird. Es ist, dass sie angefasst werden kann.