Thema: Laravel.

Laravel ist das PHP-Framework, auf dem JFconcept individuelle Webanwendungen baut: Backends, Konfiguratoren, Verzeichnisse und Kundenportale, die es als fertiges Produkt nicht zu kaufen gibt. Der greifbarste Beleg steht direkt vor dir, denn diese Website läuft selbst auf Laravel. Interessant wird das Framework immer dann, wenn ein Ablauf im Unternehmen nicht mehr in ein Plugin passt.

Wenn der Baukasten an seine Grenze kommt

Die wenigsten Projekte starten mit dem Wunsch nach Individualsoftware. Am Anfang steht meistens eine Website oder ein Shop, an den über Jahre etwas drangeschraubt wurde: ein Plugin für die Preisberechnung, ein zweites für den Formularversand, dazu eine Tabelle, in die jemand Anfragen von Hand überträgt. Das trägt lange. Es kippt in dem Moment, in dem eine Regel dazukommt, die keines der Plugins kennt.

Die Anzeichen sind fast immer dieselben:

• Preise oder Varianten hängen von Kombinationen ab, die kein Standardfeld abbildet.
• Zwei Systeme führen dieselben Daten getrennt und driften auseinander.
• Ein Arbeitsschritt existiert nur im Kopf einer einzigen Person.
• Jede neue Anforderung braucht ein weiteres Plugin, und jedes Plugin eine weitere Ausnahme.

An dieser Stelle ist die Erweiterung des Standards die teurere Lösung. Nicht wegen der Lizenzkosten, sondern weil jede Abhängigkeit die nächste Änderung langsamer macht. Genau dort beginnt unser Webengineering, und dort setzen wir Laravel ein.

Das Datenmodell steht vor dem Code

Laravel ist bei JFconcept die Basis für alles, was hinter der Oberfläche passiert: Datenmodell, Geschäftslogik, Rechte, Hintergrundprozesse. Das Frontend bauen wir getrennt davon, in der Regel mit React und TypeScript. Dieselbe Kombination trägt auch diese Seite, wir arbeiten also nicht mit einem Stack, den wir nur empfehlen.

Am Anfang eines Projekts steht bei uns nicht der Code, sondern das Datenmodell. Welche Objekte gibt es im Betrieb wirklich, wie hängen sie zusammen, welche Zustände können sie annehmen, wer darf sie ändern. Erst danach entstehen die Abläufe darauf. Diese Reihenfolge wirkt umständlich, erspart aber die teuersten Umbauten: Ein falsch geschnittenes Datenmodell lässt sich später nur mit einer Datenmigration geradeziehen, eine unpassende Bildschirmmaske wird einfach neu gebaut.

Bevor entwickelt wird, zeigen wir das Ergebnis als klickbaren Prototyp über unsere JF Design Platform. Wer die Oberfläche vorher bedient hat, merkt dort, ob ein Schritt fehlt, und nicht erst nach dem Launch. Konkret entstehen daraus Konfiguratoren mit eigenen Regelwerken, interne Datenbanken und Verzeichnisse, Kundenportale und Auswertungen. Wo eine solche Anwendung Daten mit ERP, CRM, Warenwirtschaft oder Shop teilen muss, kommen Schnittstellen und APIs dazu. Lange Aufgaben wie Importe, Exporte oder Rechnungsläufe wandern in Warteschlangen, damit niemand vor einem hängenden Browserfenster wartet.

Für die tägliche Pflege bekommt fast jedes Projekt einen eigenen Administrationsbereich, zugeschnitten auf die Begriffe des Betriebs. Wer Maschinen verwaltet, sieht dort Maschinen und keine generischen Beiträge. Dazu gehören Rollen und Rechte, damit die Buchhaltung andere Felder sieht als der Außendienst. Das entscheidet oft darüber, ob eine Anwendung nach dem Launch wirklich benutzt wird oder ob die alte Tabelle heimlich weiterlebt.

Auf derselben Basis binden wir KI dort an, wo sie einen Ablauf wirklich abkürzt: Anfragen vorqualifizieren, Dokumente auslesen, eine Suche, die Fragen versteht. Entscheidend ist der Anschluss an echte Daten aus Shop, Warenwirtschaft oder Ticketsystem. Ein Assistent auf leerer Wissensbasis ist nichts wert.

Absicherung gehört in die Entwicklung, nicht in die Nachbereitung

Individualsoftware hat kein Herstellerforum, in dem jemand den Fehler schon gefunden hat. Deshalb sichern wir jede Laravel-Anwendung schon während der Entwicklung ab, statt am Ende einmal quer zu klicken.

Automatisierte Tests mit PHPUnit halten die kritischen Abläufe fest. Rechnet die Rabattlogik nach einer Änderung anders, fällt das im Test auf und nicht beim Kunden. Jede Änderung liegt in Git und ist nachvollziehbar. Neue Stände gehen zuerst auf eine Staging-Umgebung, werden dort geprüft und freigegeben und erst danach live gestellt. Für die Auslieferung gelten messbare Ziele bei Core Web Vitals und Lighthouse, denn eine langsame Anwendung wird im Alltag genauso wenig genutzt wie eine fehlerhafte.

Laravel trägt dabei einen Teil der Arbeit selbst, weil Sicherheitsupdates, Datenbankmigrationen, Warteschlangen und Testwerkzeuge zum Framework gehören statt selbstgebaut zu sein. Das ist auch der Grund für unsere Wahl: eine breit verwendete Technologiebasis statt einer Nischenlösung. Wer Laravel kennt, findet sich im Projekt zurecht, und genau das ist beabsichtigt. Der Quellcode gehört dem Auftraggeber, Daten und Dokumentation geben wir heraus, und wo gehostet wird, entscheidet der Kunde. In Menden im Sauerland betreiben wir eine eigene, performante Serverumgebung und bieten Betrieb und Wartung optional an, aber die Software läuft auch ohne Wartungsvertrag weiter.

Woran der Erfolg sichtbar wird

Der erste Gradmesser ist eingesparte Handarbeit. Werden Daten nicht mehr zwischen zwei Systemen abgetippt, kommen Angebote aus dem Konfigurator statt aus der Tabelle und liegen Anfragen vorsortiert im Postfach, rechnet sich das Projekt in Arbeitszeit.

Der zweite Gradmesser ist die Fehlerquote: weniger Rückfragen wegen falscher Preise, weniger Korrekturen, weniger Sonderfälle, die jemand aus dem Gedächtnis löst. Diese Zahl kennt der Betrieb selbst am besten, weil er sie vorher täglich gespürt hat.

Der dritte Gradmesser zeigt sich erst nach Monaten, nämlich am Preis der nächsten Änderung. Eine saubere Struktur merkt man nicht am Launch-Tag, sondern beim zweiten und dritten Ausbau, wenn neue Anforderungen dazukommen, ohne dass das Fundament angefasst werden muss. Anwendungen wachsen so mit dem Betrieb, statt nach zwei Jahren ersetzt zu werden.