What we use Symfony for
Symfony comes in when a process cannot be bent into a standard system. Customer portals with their own roles and approvals, administrative interfaces for specialist departments, booking and application procedures, or pipelines that pull data together from several sources. Often there is an API at the end that a shop, an app or a partner system uses. The trigger is almost always a process that someone currently holds together by hand in a spreadsheet.
The second area is Shopware 6. The shop ships with Symfony, so the same rules apply there: dependency injection, events, bundles — or plugins, as Shopware calls them. If you know the framework, you do not have to rely on documentation for a Shopware extension; you can look in the code and see what actually happens. That is why shop projects and custom development do not end up in separate teams here.
How we work with Symfony
Database access runs through Doctrine, background work through Messenger with a queue, recurring tasks through console commands. Permissions are handled by the security component with voters instead of checks scattered across the code, and input is validated in one place. It sounds like bureaucracy, but it saves exactly the discussions that cost time in projects grown over years: where does this belong, and who is actually allowed to see it.
We prefer to work on the LTS versions, because a project that runs for years does not need a forced rebuild every six months. Upgrades are prepared with Rector and PHPStan instead of being hunted down by hand. Development and operation run in Docker, deployments through a pipeline with automated tests. Elasticsearch and Redis come in for search and caching, running on our own servers in Germany.
Limits and alternatives
Symfony is neither a content management system nor a shop system. If you need a website with an editorial team, TYPO3 or WordPress will get you a better result faster, and if you want to sell, Shopware 6 beats a hand-built shopping cart. A custom shop on Symfony means maintaining payment methods, tax logic, returns and legal texts yourself — permanently, not just for the launch.
There is a lower limit as well. For a form with an email notification or a small tool, a full framework is ballast; far less will do. And Symfony demands discipline: without a grasp of dependency injection and Doctrine, you quickly end up with something that looks like Symfony and behaves like a script from 2009. Custom software pays off when the process carries the business — otherwise it does not.