Wenn Ihre Logik nicht in ein Plugin passt.
Individuelle Software-Entwicklung auf Symfony und PHP: eigenständige Webanwendungen, API-Services, komplexe Workflows. Für alles, was weder als TYPO3-Extension noch als Sylius-Plugin sinnvoll ist — aber denselben Qualitätsanspruch braucht.
Standard-CMS oder Shop allein trägt Ihre Logik nicht immer.
Die Lösung
- Eigene Anwendung auf Symfony — derselbe Stack wie unsere TYPO3- und Sylius-Projekte
- Domain-Driven Design: Bounded Contexts, Aggregate, Domain Events
- API Platform als Standard-Schnittstelle — integriert sauber mit allem
- Test-first: Unit-, Integration-, Funktionstests + statische Analyse
- Kontinuierliche Integration, reproduzierbare Deployments, Doku als Code
Das Problem
- Geschäftslogik wird in eine CMS-Extension gequetscht, die dafür nie gedacht war
- Shop-Plugins, die bei jedem Update neue Konflikte auslösen
- Prozess-Workflows, die in Wahrheit eine eigene Anwendung sind
- API-Schichten, die als nachträglicher Anbau schon nach einem Jahr chaotisch sind
- Legacy-PHP-Code ohne Tests, bei dem niemand mehr anfassen will
Vier Disziplinen, die bei uns nicht verhandelbar sind
Individuelle Software-Entwicklung ist ohne diese vier Punkte in drei Jahren nicht mehr wartbar. Deshalb sind sie bei uns keine Extras, sondern Grundvoraussetzung.
Dokumentation als Code
Architektur-Diagramme, Runbooks, API-Referenzen — alles im Repo, alles versioniert, alles mit den Code-Changes mit-reviewt. Niemand hat je gesagt "gibt's da auch Doku?" und eine Absage bekommen.
CI als Security-Perimeter
Unsere CI-Pipelines sind keine Convenience-Tools — sie sind der erste Security-Layer. Signierte Builds, SBOM, Supply-Chain-Prüfungen, automatische Dependency-Updates. Nicht auf Zuruf.
Test-first, nicht test-maybe
Unit-, Integrations- und Funktionstests gehören zur Definition of Done. Statische Analyse (PHPStan) auf Stufe max. Mutation Testing in kritischen Modulen. Coverage ist ein Nebenprodukt, nicht das Ziel.
Architektur zuerst
Bounded Contexts, Aggregate, Domain Events. Architekturentscheidungen werden als ADRs dokumentiert — damit auch jemand, der in drei Jahren dazukommt, nachvollziehen kann, warum etwas so ist, wie es ist.
Wie wir arbeiten, in Artikelform
Vier Beiträge aus unserem Blog zur Engineering-Praxis — von DevOps-Grundsatz bis hin zur konkreten Case-Study.
Hunderte Stellenanzeigen, halbe Laufzeit
Case Study: Wie gezielte Code-Interventionen die Laufzeit einer Karriereseite unter Last halbiert haben — ohne Rewrite.
Standardisierung macht schlagkräftig
Warum unsere Standards uns schneller machen — nicht unflexibler. Mit Beispielen aus konkreten Projekten.
Standardisierte Individualität
Wie wir individuelle Anforderungen umsetzen, ohne dafür Betrieb und Wartbarkeit zu opfern.
compose.yaml aus allen Projekten verbannt
Warum Docker Compose aus dem Projekt-Root geflogen ist und was heute unser Standard für reproduzierbare Symfony-Umgebungen ist.
Symfony. DDD. API-first. Test-first. Kein „TODO: fix later“.
Häufig zusammen eingesetzt.
Haben Sie einen Case, der nicht in ein Plugin passt?
In 30 Minuten klären wir, ob Ihre Anforderung ein Custom-Projekt braucht — oder ob sie sich sauber in eine bestehende Plattform (TYPO3, Sylius, KI-Agent) integrieren lässt. Kostenfrei, unverbindlich.
Oder direkt schreiben: kontakt@moselwal.de