Warum Aburok auf Laravel setzt – und wann nicht

In fast jedem Erstgespräch kommt irgendwann die Frage: „Welches Framework setzen Sie eigentlich ein?" Meine Antwort ist in den meisten Mittelstands-Projekten gleich – Laravel. Dieser Beitrag erklärt, warum, und genauso wichtig, in welchen Fällen ich bewusst etwas anderes empfehle.

Die Wahl des Frameworks ist eine dieser Entscheidungen, die fünf Jahre nach Projektstart noch nachklingt. Wer hier nach Hype oder persönlicher Vorliebe entscheidet, zahlt später mit Wartungsaufwand und Personalknappheit. Deshalb lohnt es sich, die Frage einmal ehrlich auseinanderzunehmen.

15 Jahre PHP, davon viele Jahre Laravel

Wenn ich Laravel empfehle, dann nicht aus Mode, sondern weil ich den Werkzeugkasten kenne. PHP ist seit über 15 Jahren mein tägliches Arbeitsmittel. Davor lagen alte Symfony-1- und CodeIgniter-Projekte, Zend Framework, dann Symfony 7, und Laravel begleitet mich ab Version 4. Mit Laravel kommen wir heute bei den meisten Mittelstands-Anforderungen am schnellsten und am ruhigsten zum Ziel.

Erfahrung mit einem Framework ist mehr wert, als es auf den ersten Blick klingt. Wer es kennt, baut schneller und sicherer. Er weiß, wo die scharfen Kanten liegen, welche Defaults wirklich sicher sind, welche Konventionen Performance kosten und welche bequeme Abkürzung sich in zwei Jahren rächt. Diese Tiefe ersetzt kein Tutorial.

Sicherheit ohne Eigenbau

Bei vielen Frameworks muss man die Sicherheits-Grundlagen erst zusammenklauben. Laravel liefert sie in den Defaults mit, und zwar an den Stellen, an denen die typischen Fehler entstehen.

Der CSRF-Schutz ist von Anfang an aktiv, Formulare ohne @csrf-Token werden abgelehnt. Über den Query Builder und Eloquent kommt man an SQL-Injection praktisch nicht heran, ohne sich aktiv selbst zu sabotieren. Blade escaped Variablen im Template automatisch – wer nicht escapen will, muss das mit {!! !!} bewusst tun. Passwörter laufen über bcrypt oder argon2, fertig konfiguriert. Rate Limiting steht als Middleware in zwei Zeilen. Und mit Sanctum lässt sich Authentifizierung für APIs oder klassische Web-Sessions in Minuten ans Projekt schrauben, getestet und dokumentiert.

Das spart in jedem Projekt Tage, in denen sonst Sicherheits-Grundlagen handgeklöppelt würden. Wichtiger noch: Es nimmt die typischen Junior-Fehler raus, die in selbstgebauten Frameworks regelmäßig auftauchen.

Für einen Mittelständler ist das eine einfache Geschichte. Auf die Frage „Ist unsere App sicher?" lautet die Antwort für die Standard-Angriffsflächen: „Ja, das macht das Framework von Haus aus." Und der individuelle Aufwand bleibt für das, was wirklich projektspezifisch ist.

API-First, weil moderne Anwendungen es brauchen

Fast jede ernsthafte Anwendung hat heute einen API-Layer. Mal für eine mobile App, mal für ein Frontend in React oder Vue, mal für eine externe Software, die andocken will, mal für einen Zahlungsanbieter oder einen KI-Telefonassistenten. Laravel macht hier vieles angenehm. API-Resources verwandeln ein Eloquent-Model in eine saubere JSON-Antwort, mit Versionierung, Conditional Fields und Pagination. Sanctum liefert API-Token-Auth in einer halben Stunde, inklusive Scopes und Token-Widerruf. Resource Routes legen mit einer Zeile fünf Standard-Endpunkte an. Validierung und Authorisierung leben in Form Requests, sauber getrennt vom Controller.

Wenn morgen jemand sagt „Wir brauchen daneben auch noch GraphQL", lässt sich das mit Lighthouse in Tagen ergänzen, ohne den Rest umzubauen.

Ein Beispiel aus unserer Praxis: Eine HR-Anwendung mit einem Web-Frontend in Blade, einer mobilen App auf React Native, einem nächtlichen ERP-Sync über REST und einem wöchentlichen Lohnschnittstellen-Export per SFTP. Alles aus einem Laravel-Codebase, und keine dieser Schnittstellen bricht, wenn an einer anderen geschraubt wird.

In fünf Jahren noch wartbar

Mittelständische Software lebt typischerweise fünf bis zehn Jahre. Wer in dieser Zeitspanne denkt, achtet auf zwei Dinge: dass das Framework noch da ist, und dass jemand den Code noch lesen kann.

Laravel hat regelmäßige Release-Zyklen, eine LTS-Schiene und seit Jahren eine sehr lebendige Community. Major-Updates kommen jährlich, lassen sich aber in der Regel mit überschaubarem Aufwand migrieren. Wir haben mehrere Kunden-Codebases von Version 8 über 9 und 10 bis 11 migriert, meist innerhalb einer Woche pro Major-Sprung. Das ist deutlich weniger Schmerz als bei vielen vergleichbaren Stacks.

Die Konventionen helfen mehr, als es klingt. Wer Laravel kennt, findet sich in jeder Laravel-Codebase schnell zurecht. MVC, Controller-Verzeichnis, Eloquent-Models, Service-Provider, Middleware – alles am gleichen Platz. Ein neuer Entwickler im Projekt ist produktiv, ohne dass jemand erst die Eigenheiten der Codebase erklären muss.

Genauso wichtig: PHP- und Laravel-Entwickler sind in Deutschland gut verfügbar. Wenn wir ein Projekt übergeben oder erweitern, kennt der Folgeentwickler das Framework mit hoher Wahrscheinlichkeit. Bei manchen exotischen Stacks muss man den entweder teuer einfliegen oder lange einarbeiten.

Datenbankänderungen laufen über Migrationen in Code, nicht über Excel oder manuelles SQL beim Deploy. Damit ist jede Änderung reproduzierbar, dokumentiert und versioniert. Tests sind mit PHPUnit oder Pest fester Bestandteil des Frameworks, keine separate Welt. Wir liefern unsere Software grundsätzlich mit Test-Suiten aus – und sind oft selbst der Hauptnutzer dieser Tests, wenn wir Jahre später Erweiterungen einbauen.

Das Ecosystem macht den Unterschied

Ein Framework ohne Ecosystem zwingt zum Selbstbauen jeder zweiten Komponente. Bei Laravel ist in den letzten Jahren eine Welt von ausgereiften Paketen entstanden, die fast jede Standard-Anforderung abdecken.

Die Bibliotheken von Spatie nutzen wir in praktisch jedem Projekt – Permission, MediaLibrary, ActivityLog, Backup. Eine belgische Agentur pflegt diese seit über zehn Jahren, sauber getestet, gut dokumentiert. Wie wir Spatie Permission konkret in HR-Apps einsetzen, steht in unserem Beitrag zu Rollen und Rechten mit Spatie Permission.

Für interaktive Frontends ohne komplette Single-Page-App-Architektur sind Livewire und Inertia mittlerweile sehr ausgereift. Filament beschleunigt Admin-Panels enorm und ist trotzdem flexibel genug, um eigene Anforderungen abzubilden. Wer Job-Queues mit Redis braucht – etwa für E-Mail-Versand, KI-API-Calls oder PDF-Generierung –, bekommt mit Horizon ein Monitoring frei Haus. Stripe- und Paddle-Subscriptions handelt Cashier praktisch vorgefertigt.

Jedes dieser Pakete bedeutet konkret: Wochen Eigenentwicklung gespart, getestete Komponenten von erfahrenen Teams.

Was wir damit konkret bauen

In unserer Praxis passt Laravel besonders gut für individuelle Business-Software – CRM-Erweiterungen, interne Tools, Workflow-Anwendungen. Für API- und Schnittstellen-Entwicklung sowieso, weil das Framework dafür gemacht ist. KI-Integrationen wie OpenAI- oder Anthropic-Calls binden wir in Laravel-Apps in Stunden statt Tagen ein, mit Queue-basierten Aufrufen, Rate Limiting und Audit-Log. Für E-Commerce-Lösungen bauen wir oft maßgeschneiderte Headless-Backends hinter einem React- oder Vue-Frontend, manchmal kombiniert mit Shopware. Und alles davon containerisiert, gehostet auf Hetzner Cloud in Falkenstein oder Nürnberg, oder bei AWS Frankfurt – DSGVO-konform in Deutschland.

Wann ich kein Laravel empfehle

Damit der Beitrag ehrlich bleibt: Es gibt Fälle, in denen Laravel nicht die richtige Wahl ist.

Hat ein Kunde bereits eine ausgewachsene Spring-Boot-Codebase, ist es meistens ein Fehler, etwas Neues daneben zu setzen. Dann bauen wir mit Java weiter – das gehört seit Jahren ebenfalls zu unserem Stack.

Wenn die Anwendung im Kern auf Mikrosekunden-Latenz oder massiver Parallelität lebt – etwa Trading-Backends, IoT-Gateways mit Hunderten Geräten pro Sekunde –, dann ist PHP nicht die erste Wahl. Hier sind Go, Rust oder Node.js mit Worker-Threads häufig die besseren Werkzeuge.

Für reine Data-Science-Aufgaben – Machine-Learning-Modelle, Datenanalyse-Pipelines, NumPy- oder Pandas-Arbeit – ist Python das richtige Werkzeug. Laravel wird dann höchstens noch zur Bedienoberfläche oder zum API-Wrapper.

Mobile-Native-Apps bauen wir mit React Native, Cordova oder nativem iOS/Android-Tooling. Laravel liefert dabei das Backend, nicht die App selbst.

Der gemeinsame Nenner: Tool für den Job, nicht Tool zuerst. Das ist auch einer der Punkte, an denen wir uns als Aburok von reinen Framework-Fanatikern unterscheiden – technologieoffen, nicht ideologisch.

Was das für unsere Kunden bedeutet

Drei Versprechen, die sich aus dieser Wahl konkret ergeben. Erstens: In fünf Jahren findet sich noch jemand, der den Code wartet. Laravel ist im deutschsprachigen Raum keine Exoten-Technologie. Zweitens: Die Standard-Sicherheitslücken sind ab Tag eins zu, und wir bauen darauf auf, statt sie nachträglich zu stopfen. Drittens: Erweiterungen sind in Tagen oder Wochen möglich, weil das Ecosystem 80 Prozent abdeckt und unser Aufwand für das wirklich Projektspezifische bleibt.

Und natürlich: Der Code gehört dem Kunden, kein Vendor-Lock-in, keine Lizenzfallen.

Wenn Sie selbst vor der Framework-Entscheidung stehen

Wenn Sie gerade ein neues Projekt planen oder ein bestehendes modernisieren wollen und sich fragen, ob Laravel der richtige Weg wäre: Sprechen Sie mit uns. In einem kostenfreien 30-Minuten-Erstgespräch schauen wir uns Ihre Situation an und sagen ehrlich, ob Laravel passt – und wenn nein, was besser passen würde.

Erstgespräch unverbindlich vereinbaren – wir melden uns innerhalb eines Arbeitstages.