Chiptuning-Plattform für digitale Dateiservices

Im Kern ist die Plattform ein digitaler Tuningfile-Service: Ein Kunde lädt die Steuergerätedatei seines Fahrzeugs hoch und erhält eine bearbeitete Tuning-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: Kundenkonten, ein Händlerportal mit mehrstufiger Struktur und eigenen Konditionen, ein Guthabenkonto statt eines Warenkorbs, mehrere Zahlungswege, ein Fahrzeug- und Produktkatalog aus externen Datenquellen, Rechnungen, Auswertungen, Protokollierung. Jede dieser Erweiterungen kam in ein System, das bereits lief.

Die Aufgabe war deshalb nie, das Richtige einmal zu bauen. Sie war, eine Chiptuning-Software über Jahre entwicklungsfähig zu halten — fachlich und technisch zugleich.

Der Weg einer Datei durch das System ist das Produkt. Er muss zwei Fälle tragen, die von außen gleich aussehen und intern nichts miteinander zu tun haben: Deckt der vorhandene Dateibestand die Anfrage bereits ab, steht das Tuningfile nach wenigen Schritten bereit. Tut er es nicht, beginnt an derselben Stelle ein individueller Bearbeitungsauftrag mit eigenem Status.

Wichtig ist dabei auch, was nicht passiert. Das System liest die hochgeladene Steuergerätedatei nicht aus, erkennt kein Fahrzeug und errät nichts. Der Abgleich ist ein Prüfsummenvergleich gegen den vorhandenen Dateibestand — 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.

Abgerechnet wird nicht pro Bestellung, sondern über ein Guthabenkonto. Das klingt einfacher als ein Warenkorb und ist es nicht: Es gibt mehrere Guthabenarten nebeneinander, darunter zeitlich befristetes Guthaben, und jede Buchung muss im Nachhinein erklärbar bleiben. Unter dem Kontostand liegt deshalb eine vollständige Transaktionshistorie und kein einzelnes Feld.

Aufgeladen wird über mehrere Zahlungswege — PayPal, Klarna und Sofortüberweisung —, die jeweils eigene Abläufe, eigene Rückmeldungen und eigene Fehlerfälle mitbringen. Die Zahlungsabwicklung läuft deshalb nicht im Anfrage-Zyklus, sondern in eigenen Hintergrundprozessen; Rechnungen entstehen im Anschluss automatisch als PDF.

Ein Zahlungsweg, der später dazukommt, ist in einem solchen System nie nur eine Integration. Er ist eine weitere Art, wie Geld in ein bestehendes Guthabenmodell gelangt — und muss sich in eine Buchungslogik einfügen, die schon da ist.

Ein Framework altert schneller als das Geschäft, das darauf läuft. Diese Chiptuning-Plattform wurde über mehrere Laravel-Generationen weitergeführt — von Laravel 5.x bis Laravel 10. Keiner dieser Schritte war ein Neubau.

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, die technische Grundlage wurde mehrfach erneuert. Was Software langlebig macht, ist nicht, dass sie nie angefasst wird. Es ist, dass sie angefasst werden kann.