Wenn eine Laravel-Anwendung das erste Entwicklungsstadium verlässt

Viele Probleme in der Softwareentwicklung werden fälschlicherweise auf mangelnde Entwicklergeschwindigkeit oder -kompetenz zurückgeführt.

Ein Manager oder Gründer bemängelt, dass Features zu lange für die Entwicklung benötigen. Die Kommunikation mit dem Dienstleister gestaltet sich schwierig oder wirkt fragmentiert. Fehler und Probleme tauchen nach Änderungen immer wieder auf. Die Anwendung und Workflows brechen zu häufig zusammen. Das Unternehmen möchte skalieren, doch es gibt ernste Zweifel und Vertrauensprobleme mit der Plattform. Auf den ersten Blick scheint dies ein Lieferproblem zu sein, das möglicherweise durch den Wechsel des Dienstleisters oder die Hinzunahme weiterer Entwickler gelöst werden könnte, in der Hoffnung, Features und Änderungen schneller umsetzen zu können.

In diesem Fall wäre dies jedoch die völlig falsche Diagnose und Lösung gewesen.

Der Kunde in dieser Analyse ist ein betriebsintensives Logistikunternehmen mit einer maßgeschneiderten Anwendung auf Basis des Laravel-Frameworks im Zentrum seines Geschäfts. Die Plattform verwaltete die Kundenakquise, Schiffs- und Auftragsplanung, Fahrer- und/oder Partnerzuweisungen, Statusaktualisierungen, Preisberechnungen, Rechnungsstellung, Zahlungseingang, internes Task-Management, Admin-Dashboard und andere integrierte Funktionen.

Mit anderen Worten: Dies war keine Nebenanwendung für spezielle Betriebsabläufe innerhalb der Organisation. Es handelte sich um das operative Rückgrat des Unternehmens.

Das eigentliche Problem bestand jedoch nicht darin, dass die Entwicklung langsam war und die Kommunikation eine Herausforderung darstellte. Die Anwendung war über das Entwicklungsmodell hinausgewachsen, das sie geschaffen hatte: Sie war von einem Entwickler gestartet worden, von anderen erweitert und später von einem externen Team weiterentwickelt worden. Jede Gruppe hatte zur Systementwicklung beigetragen, doch es gab keine durchgängige technische Verantwortung während dieser Zeit für die gesamte Plattform. Mit der Zeit wurde der Code immer komplexer, und es wurden zunehmend Verknüpfungen eingeführt, wodurch die Codebasis schwerer zu analysieren und infolgedessen schwerer zu ändern wurde.

Dies ist eine gefährliche Phase für ein Unternehmen: Die Software ist zu wichtig, um sie zu ignorieren, zu groß, um sie einfach neu zu schreiben, und zu instabil, um sie ohne Eingreifen weiter zu skalieren und zu ändern. Die Entscheidung, die Software vollständig durch ein anderes generisches Produkt zu ersetzen, birgt versteckte Risiken und ist mit den Kosten für die Umschulung des Personals und die Suche nach Lösungen für sehr spezifische Workflows verbunden. Darüber hinaus würde dies bedeuten, dass Jahre der Investitionen in die aktuelle Plattform aufgegeben werden müssten – was sehr wahrscheinlich überhaupt nicht notwendig ist.

Der Kunde dachte, er hätte ein Problem mit der Feature-Lieferung

Als der Kunde uns kontaktierte, waren die offensichtlichen Beschwerden nur allzu vertraut: Features benötigten zu lange für die Entwicklung. Fehler tauchten nach der Behebung wieder auf. Neue Änderungen beschädigten bestehende Funktionen. Änderungen verletzten festgelegte Geschäftslogik oder entsprachen nicht genau dem, was der Kunde für vereinbart hielt. Die Anwendung wurde unter stärkerer operativer Nutzung unzuverlässig. Die Kommunikation mit dem vorherigen Dienstleister war stets eine Herausforderung, und es fiel dem Kunden, der kein technischer Experte war, schwer, seine Ideen und Wünsche klar zu vermitteln. Dies führte zu unnötigen Korrekturschleifen, die teuer waren. Der Gründer wollte skalieren, doch die Software zog die Aufmerksamkeit immer wieder in den täglichen Krisenmodus.

Diese waren echte Probleme, absolut. Doch sie waren auch Symptome, nicht die Ursache.

Die geschäftlichen Auswirkungen waren ernster als ein verzögerter Backlog. Der Gründer verbrachte zu viel Zeit mit der Verwaltung von Softwareproblemen und versuchte schließlich, den Anbieter zu managen, anstatt das Unternehmen zu wachsen. Operative Fehler beeinträchtigten die Kundenzufriedenheit. Das Team begann, das Vertrauen in die Plattform zu verlieren. Die Skalierung des Unternehmens würde nicht nur die Nutzung erhöhen, sondern alle diese Fehlerquellen vervielfachen.

Viele Unternehmen befinden sich derzeit in dieser Phase und beginnen, über ein Ersatzsystem nachzudenken. Doch der komplette Austausch der Plattform ist oft weder die erste verantwortungsvolle noch eine notwendige Maßnahme. Ein Neuschreiben ist teuer, riskant, langsam und störend. Wenn das aktuelle System weiterhin wertvolle und gültige Geschäftslogik enthält und reale Operationen unterstützt, hat die Priorität meist die Stabilisierung und die Bewältigung der akutesten Probleme.

Dies war der Ansatz, den wir hier gewählt haben.

Was wir in der Laravel-Anwendung vorgefunden haben

Der Anwendungsstack, als wir die Kontrolle über ihn übernommen haben, bestand aus Laravel 8, PHP 8.0, einem hybriden VueJS-Frontend und MySQL. Er umfasste Zahlungs- und Rechnungsintegrationen, Hintergrundaufgaben, Kommunikation mit externen APIs und geschäftskritische Workflows rund um Logistikoperationen.

Laravel 8 war bereits veraltet, aber die Framework-Version war nicht das dringendste Problem. Die tieferen Probleme waren architektonischer und operativer Natur:

• Kritische Geschäftslogik befand sich in sehr großen Controllern
• Die gleichen Geschäftsregeln wurden in verschiedenen Teilen des Systems unterschiedlich umgesetzt.
• Es gab keine sinnvollen automatisierten Tests für die Kern-Workflows.
• Das Datenbankschema war ohne klares architektonisches Modell gewachsen.
• Migrations waren fragil.
• Die Verarbeitung von Warteschlangen und Aufgaben war unzuverlässig.
• Fehlgeschlagene Hintergrundaufgaben konnten falsche operative Datensätze erzeugen oder operative Daten in einem teilweise abgeschlossenen Zustand hinterlassen.
• Fehler bei externen APIs wurden nicht konsistent behandelt.
• Die Beobachtbarkeit war minimal bis nicht vorhanden.
• Fehler in Warteschlangen blieben oft unsichtbar, bis ein Kunde oder Operator etwas falsch lief.
• Zahlungs- und Rechnungszustände konnten unzuverlässig werden.
• Der Codierungsstil und die Implementierungsqualität variierten stark in verschiedenen Teilen des Quellcodes.
• Es gab keinen klaren technischen Verantwortlichen, der für die langfristige Gesundheit der Plattform zuständig war.

Die aufschlussreichste Entdeckung war, dass ein kritischer Workflow größtenteils in einem massiven Controller existierte, von dem Teile von anderen Controllern verwendet wurden. Dieser Controller erledigte zu viel, war mit anderer Logik verflochten, enthielt doppelte Logik und vermischte Geschäftsentscheidungen mit Implementierungsdetails.

Eine solche Struktur schafft eine versteckte Steuerlast für jede zukünftige Änderung: Ein Entwickler kann möglicherweise ein Feature schnell einmal oder zweimal hinzufügen, aber mit der Zeit wird jede Änderung gefährlicher, weil niemand leicht vorhersagen kann, was sonst noch kaputt gehen könnte.

Das eigentliche Problem war die Verantwortung, nicht die Kompetenz

Es wäre einfach, aber fahrlässig und möglicherweise unfair, dies als "die vorherigen Entwickler haben schlechte Arbeit geleistet und waren inkompetent" zu betrachten.

Das ist nicht die nützliche Lehre, die man aus dieser Situation ziehen sollte.

Die genauere Diagnose ist, dass das System durch mehrere Hände gegangen war, ohne einen verantwortlichen technischen Eigentümer. Verschiedene Beiträger lösten unmittelbare Probleme, aber niemand war für das gesamte System als langfristiges Geschäftsvermögen verantwortlich.

Dieser Unterschied ist weitaus wichtiger, als die meisten Menschen ahnen.

Ein Entwickler setzt eine Funktion um. Ein Dienstleister schließt Tickets ab. Doch eine geschäftskritische Plattform braucht jemanden, der die Architektur, Zuverlässigkeit, Bereitstellungsdisziplin, allgemeine Beobachtbarkeit, technische Schulden und die Abwägung zwischen Geschäftsdruck und technischem Risiko verantwortet.

Ohne diese Verantwortung kann eine Laravel-Anwendung zwar weiterwachsen, aber ungleichmäßig. Controller werden überlastet, Geschäftsregeln verbreiten sich in der gesamten Anwendung, Code wird dupliziert, Warteschlangen werden fragil, Integrationen unvorhersehbar und Releases riskant. Als Folge wird der Gründer oder Hauptverantwortliche zum Ansprechpartner für jedes Softwareproblem.

In diesem Stadium benötigt ein Unternehmen nicht nur Entwicklungsressourcen: Es braucht technische Verantwortung und Ownership.

Warum wir stabilisierten, bevor wir aktualisierten

Ein häufiger Fehler bei veralteten Laravel-Anwendungen ist, direkt mit der Modernisierung des Frameworks und der Infrastruktur zu beginnen: Laravel aktualisieren, PHP aktualisieren, Pakete ersetzen, Frontend aufräumen, Infrastruktur verlagern, Module neu schreiben.

Diese Maßnahmen sind zwar notwendig und langfristig sinnvoll, aber die Reihenfolge ist entscheidend.

In diesem Fall hätte ein zu frühes Upgrade das Risiko eher erhöht als verringert. Der Code hatte ungleichmäßige Qualität, unzureichende Testabdeckung, fragile Geschäftslogik und kaum Beobachtbarkeit. Ein Framework-Update unter diesen Bedingungen hätte – wie wir es oft erlebt haben – neue Fehler eingeführt, ohne dem Team eine zuverlässige Möglichkeit zu geben, diese vor der Produktion zu erkennen. Die Aktualisierung der Frameworks, Pakete und Umgebung hätte die Situation verschlimmert statt verbessert und zu mehr Frust bei den Mitarbeitern sowie zu einem negativen Erlebnis für die Kunden geführt.

Deshalb entschieden wir uns für eine Priorisierung und Stabilisierung.

Das anfängliche Ziel war nicht, das System perfekt zu machen. Es ging darum, die wichtigsten Arbeitsabläufe so zuverlässig zu gestalten, dass das Unternehmen weiterbetrieben und wachsen konnte. Dafür konzentrierten wir uns auf die Teile der Anwendung, bei denen ein Ausfall die höchsten geschäftlichen Kosten hatte.

Die erste Stabilisierungsphase

Die erste Phase dauerte etwa sechs Wochen.

In dieser Zeit reduzierten wir die größten operativen Risiken und machten unsichtbare Probleme sichtbar.

Die Arbeit umfasste:

• Code- und Produktionsrisiko-Überprüfung.
• Einführung von Fehlerverfolgung und Beobachtbarkeit.
• Sichtbarmachung von fehlgeschlagenen Jobs, langsamen Abfragen, Benutzerfehlern, Zahlungsproblemen, Rechnungsfehlern und Bereitstellungsproblemen.
• Stabilisierung der Warteschlangen- und Jobverarbeitung.
• Verbesserung der Handhabung von Fehlern externer APIs.
• Refaktorisierung kritischer Geschäftsabläufe.
• Auslagerung duplizierter Geschäftslogik aus Controllern in Service-Klassen.
• Hinzufügen von Regressionstests für die wichtigsten Arbeitsabläufe.
• Sicherere Bereitstellung von Entwicklung, Staging und Produktion.
• Einführung von GitLab CI/CD-Automatisierung.
• Übernahme der Bereitstellungsverantwortung.
• Etablierung von Codierungsstandards und einem strukturierteren Lieferprozess.

Das war keine glamouröse Arbeit, aber notwendige. Bevor weitere Funktionen hinzugefügt und das System aus Sicherheitsgründen aktualisiert wurde, musste es erst sicherer für Änderungen werden.

Das Warteschlangenproblem war nicht nur technisch

Das Hintergrundaufgabensystem gehörte zu den wichtigsten Bereichen, die stabilisiert werden mussten.

Aufgaben scheiterten oft unbemerkt oder ignorierten Ausnahmen. Einige hatten Nebenwirkungen, die in Randfällen Probleme in anderen Teilen der Software verursachten. Fehler bei externen APIs wurden nicht korrekt behandelt. Gescheiterte Aufgaben erforderten manchmal manuellen Eingriff und Datenbankreparaturen. Queue-Worker wurden nicht richtig überwacht. Es gab keine zuverlässige Überwachung, um festzustellen, ob operative Hintergrundprozesse ausgefallen waren.

Für eine Logistikplattform stellt das ein ernstes Risiko dar.

Eine gescheiterte Hintergrundaufgabe ist nicht nur ein technischer Fehler. Sie kann falsche Zustände, fehlende Benachrichtigungen, unterbrochene Rechnungsflüsse, verzögerte operative Aufgaben oder Kundenfehler verursachen.

Sobald die Beobachtbarkeit eingeführt wurde, konnte das Team erkennen, was tatsächlich in der Produktion passierte. Gescheiterte Aufgaben, Ausnahmen, langsame Abfragen, Zahlungs- und Rechnungsprobleme, bereitstellungsbezogene Probleme und benutzerseitige Fehler wurden sichtbar.

Diese Sichtbarkeit veränderte die Arbeitsweise.

Anstatt auf Kundenmeldungen zu warten, konnten wir Randfälle sofort identifizieren, die Geschäftslogik optimieren, wiederkehrende Fehlerquellen beheben und die Plattform mithilfe von Erkenntnissen aus der tatsächlichen Nutzung verbessern.

Refaktorisierung der Kern-Geschäftslogik

Die erste große Refaktorierungsmaßnahme zielte darauf ab, die umfangreichen Controller zu entwirren, die die zentrale Geschäftslogik verwalteten. Das Problem lag nicht nur in ihrer Größe. Die Controller enthielten doppelte Logik, inkonsistente Implementierungen und unterschiedliche Interpretationen derselben Geschäftsregeln.

Das machte die Plattform anfällig.

Bei neuen Funktionsanforderungen bestand das Risiko nicht nur darin, ob die Funktion umgesetzt werden konnte. Vielmehr bestand die Gefahr, dass die Änderung versehentlich die Preisgestaltung, Job-Planung, Statusverarbeitung, Zuweisungslogik, Rechnungsstellung oder einen anderen verwandten Arbeitsablauf beeinträchtigen würde.

Wir verlagerten die doppelte Logik in dedizierte Service-Klassen und begannen, Regressionstests für wichtige Arbeitsabläufe hinzuzufügen. Ziel war nicht akademische Code-Sauberkeit, sondern die Gewinnung operativer Kontrolle über die Software und die damit verbundenen Prozesse.

Das Unternehmen musste weiterhin Änderungen anfordern. Die Plattform musste diese Änderungen unterstützen, ohne bestehende Logik zu brechen.

Wartbarkeit musste kommerziell werden, nicht nur theoretisch.

Das Liefermodell veränderte sich genauso wie der Code

Die technische Arbeit war natürlich in vielerlei Hinsicht bedeutend, doch die größere Veränderung betraf die technische Verantwortung.

Binarika übernahm die Verantwortung für die technischen Implementierungen, Bereitstellungen, Funktionsüberprüfungen, die Priorisierung technischer Schulden sowie die Balance zwischen Geschäftsziele und Engineering-Risiko.

Die Kommunikation veränderte sich ebenfalls. Statt fragmentierter Lieferantenkommunikation gab es direkten Austausch mit dem Gründer und dem Betriebsteam. Das half uns, die Hauptprozesse und Arbeitsabläufe in der Organisation zu verstehen. Das Backlog-Grooming wurde strukturierter. Die Bereitstellungen sicherer. Entwicklung, Staging und Produktionsumgebungen wurden Teil eines kontrollierten Prozesses, statt eine Quelle von Unsicherheit zu sein.

GitLab CI/CD-Automatisierung half, Disziplin vor der Produktionsbereitstellung durchzusetzen. Tests, Sicherheitslückenprüfungen, Compliance-Prüfungen und Bereitstellungskontrollen wurden Teil des Lieferprozesses.

Das ist der Teil, den viele Unternehmen allzu oft unterschätzen.

Fragile Anwendungen lassen sich selten allein durch Code-Änderungen beheben. Sie erfordern auch ein anderes Betriebsmodell rund um den Code.

Wichtige Fragen für jede individuelle Softwareanwendung sind: Wer entscheidet, welche Probleme zuerst behoben werden? Wer bewertet, ob ein Feature bereit für den Release ist? Wer ist für Produktionsprobleme zuständig? Wer kommuniziert technische Risiken im Unternehmen? Wer stellt sicher, dass technische Schulden rechtzeitig getilgt werden, bevor sie zum Wachstumshemmnis werden?

Ohne klare Antworten kehren dieselben Probleme immer wieder zurück.

Warum es keine vollständige Neuentwicklung war

Der Kunde bat nicht um eine Neuentwicklung, und wir empfahlen dies auch nicht. Ebenso wenig schlugen wir den kompletten Austausch der Plattform vor. Das hätte eine enorme finanzielle und operative Belastung bedeutet und die dringend benötigten Verbesserungen verzögert.

Stattdessen einigten wir uns auf einen pragmatischen Ansatz: gezielte Refaktorisierung der Kern-Geschäftslogik, Stabilisierung der risikoreichsten Workflows und schrittweise Verbesserung der Plattform.

Dieser Ansatz barg natürlich Risiken, die wir transparent kommunizierten. Die Stabilisierung und Modernisierung eines bestehenden Systems erfordert Disziplin. Man muss innerhalb klarer Grenzen arbeiten. Man muss das Flugzeug verbessern, während es noch fliegt. Für diesen Kunden war es jedoch eindeutig die verantwortungsvollere Lösung.

Ein guter Engineering-Partner sollte ein von Gründern geführtes Unternehmen – oder überhaupt jedes Unternehmen – nicht in die teuerste technische Option drängen, nur weil sie theoretisch sauberer ist. Das wäre ein akademisch motivierter Ansatz ohne viel Bezug zur Praxis. Die richtige Lösung muss die Geschäftswirklichkeit, die Liquidität, den operativen Druck und die Tatsache berücksichtigen, dass das System bereits täglich genutzt wird.

Mehr als zwei Jahre später ist Binarika weiterhin Eigentümer und Betreiber der Plattform.

Das ist der Kernpunkt und die zentrale Erkenntnis. Das Engagement war keine einmalige Aufräumaktion. Es entwickelte sich zu einer langfristigen technischen Verantwortung und strategischen Partnerschaft mit dem Kunden.

Was sich nach der Stabilisierung änderte

Die Plattform wurde nicht perfekt. Kein echtes Produktionssystem ist das jemals. Doch die operative Realität veränderte sich deutlich.

Fehler und Ausnahmen traten im Vergleich zum vorherigen Zustand seltener auf. Wenn sie auftraten, waren sie sofort sichtbar, priorisiert und wurden oft behoben, bevor der Kunde überhaupt von einem Problem erfuhr. Die Feature-Lieferung wurde schneller, da Änderungen auf einer stabileren Grundlage vorgenommen wurden. Neue Features beeinträchtigten aufgrund ausführlicher automatisierter Tests weniger wahrscheinlich bestehende Geschäftslogik. Releases wurden durch CI/CD-Automatisierung vorhersehbarer.

Der Gründer musste sich nicht mehr täglich mit Software-Feuerwehrarbeit befassen. Das Operationsteam gewann das Vertrauen in das System zurück. Die Plattform konnte ein größeres operatives Volumen unterstützen. Neue Automatisierungen wurden möglich, darunter interne Aufgabenvergabe, Berichterstattung und Admin-Workflows, operative Erinnerungen und Eskalationen, Zuweisungsworkflows sowie automatisierte Benachrichtigungen.

Als der richtige Zeitpunkt nach der Stabilisierung und Einführung umfassender automatisierter Tests gekommen war, hoben wir die Plattform schrittweise auf neuere Framework-Versionen und Umgebungs-Upgrades. So schafften wir eine sichere, aktuelle und stabile Plattform – ohne neue Fehler und Probleme einzuführen und, was noch wichtiger ist, ohne die Arbeit des Kunden-Teams zu unterbrechen.

Das System wurde auch kostengünstiger und einfacher zu bedienen, da sich die Bereitstellungs- und Infrastrukturentscheidungen verbessert hatten.

Am wichtigsten war, dass sich das Unternehmen wieder auf sein Kerngeschäft konzentrieren konnte. Das Logistikunternehmen konnte sich auf die Logistik konzentrieren, Binarika auf die Software.

Diese klare Aufgabenverteilung ist oft der Ort, an dem der echte Mehrwert entsteht.

Die Lehre für Unternehmen mit individueller Software

Wenn Ihr Unternehmen von einer individuellen Softwareanwendung wie das Unternehmen in dieser Analyse von dieser individuellen Laravel-Anwendung abhängt, dann ist die langsame Feature-Lieferung möglicherweise nicht das eigentliche Problem.

Das eigentliche Problem könnte sein, dass die Anwendung ihr ursprüngliches Entwicklungsmodell überstiegen hat.

Das zeigt sich meist durch vertraute Symptome:

• Features benötigen zu lange für die Entwicklung.
• Fehler tauchen immer wieder auf.
• Neue Änderungen stören bestehende Arbeitsabläufe.
• Hintergrundaufgaben scheitern unbemerkt.
• Geschäftsregeln sind inkonsistent.
• Niemand vertraut den Daten vollständig.
• Releases wirken riskant.
• Der Gründer wird zu oft in Software-Entscheidungen einbezogen.
• Das Team beginnt, eine vollständige Neuentwicklung zu diskutieren, weil das aktuelle System unkontrollierbar erscheint.

Eine (teilweise) Neuentwicklung könnte notwendig sein. Ein Framework-Update könnte notwendig sein. Eine Modernisierung der Infrastruktur könnte notwendig sein.

Aber die erste Frage sollte einfacher sein:

Wer ist technisch, operativ und kommerziell für das System verantwortlich?

Wenn die Antwort unklar ist, wird die Hinzunahme weiterer Entwickler das zugrunde liegende Problem nicht lösen. Es könnte das System sogar schwerer kontrollierbar machen.

Eine geschäftskritische Plattform wie diese Laravel-Anwendung benötigt mehr als die Abarbeitung von Tickets. Sie benötigt technische Verantwortung, Beobachtbarkeit, Architekturdisziplin, sichere Bereitstellungen, Schutz vor Regressionen und eine Roadmap, die Software-Entscheidungen mit den Geschäftsprioritäten verbindet.

Das ist der Punkt, an dem Rettungsarbeit in eine langfristige Partnerschaft übergeht.

Nicht, weil das ursprüngliche System wertlos war. Nicht, weil frühere Entwickler inkompetent waren. Sondern, weil das Unternehmen eine Phase erreicht hatte, in der die Software ein höheres Maß an Verantwortung benötigte.

Für Unternehmen und Organisationen in dieser Situation geht es nicht darum, die Codebasis perfekt zu machen.

Es geht darum, die Kontrolle zurückzugewinnen.