When your logic doesn't fit into a plugin.
Custom engineering on Symfony and PHP: standalone web applications, API services, complex workflows. For everything that makes no sense as a TYPO3 extension or a Sylius plugin — but needs the same quality standard.
Standard CMS or shop alone does not always carry your logic.
The solution
- Standalone application on Symfony — the same stack as our TYPO3 and Sylius projects
- Domain-Driven Design: bounded contexts, aggregates, domain events
- API Platform as the standard interface — integrates cleanly with anything
- Test-first: unit, integration, functional tests + static analysis
- Continuous integration, reproducible deployments, documentation as code
The problem
- Business logic squeezed into a CMS extension that was never meant for it
- Shop plugins that trigger new conflicts with every update
- Process workflows that are in fact a separate application
- API layers that, as a retrofit, become chaotic within a year
- Legacy PHP code without tests that nobody dares touch any more
Four disciplines that are non-negotiable for us
Without these four points, custom engineering becomes unmaintainable within three years. That is why they are not extras for us — they are basic prerequisites.
Documentation as code
Architecture diagrams, runbooks, API references — all in the repo, all versioned, all reviewed alongside the code changes. Nobody has ever asked “is there documentation for this?” and been turned away.
CI as security perimeter
Our CI pipelines are not convenience tools — they are the first security layer. Signed builds, SBOM, supply-chain checks, automated dependency updates. Not on request.
Test-first, not test-maybe
Unit, integration and functional tests are part of the Definition of Done. Static analysis (PHPStan) at maximum level. Mutation testing in critical modules. Coverage is a by-product, not the goal.
Architecture first
Bounded contexts, aggregates, domain events. Architectural decisions are documented as ADRs — so that even someone joining three years from now can understand why something is the way it is.
How we work, in article form
Four blog posts on engineering practice — from DevOps principles through to a concrete case study.
Hundreds of job ads, half the runtime
Case study: how targeted code interventions cut the runtime of a careers site under load in half — without a rewrite.
Standardisation makes you effective
Why our standards make us faster — not less flexible. With examples from real projects.
Standardised individuality
How we deliver bespoke requirements without sacrificing operations and maintainability.
compose.yaml banished from every project
Why Docker Compose flew out of the project root, and what is now our standard for reproducible Symfony environments.
Symfony. DDD. API-first. Test-first. No “TODO: fix later”.
Häufig zusammen eingesetzt.
Do you have a case that doesn't fit into a plugin?
In 30 minutes we will work out whether your requirement needs a custom project — or whether it can be cleanly integrated into an existing platform (TYPO3, Sylius, AI Agent). Free of charge, no obligation.
Oder direkt schreiben: kontakt@moselwal.de