Technology · Framework

Symfony — framework for custom software and the foundation of Shopware 6

Symfony is our framework for everything no standard system covers: backends, portals, processing pipelines, APIs. It is also what Shopware 6 is built on, which is why shop work and custom development stay in the same hands here. Anyone who understands Symfony also knows what happens beneath the surface of a Shopware project.

our framework for custom software

What is Symfony?

Symfony is a PHP framework: a kit of proven components for building individual applications without rebuilding the basics every time.

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.

Projects with Symfony

A selection — not the full client list.

Frequently asked questions

When is Symfony worth it compared with a standard system?

Symfony is worth it as soon as the process itself is the unusual part, rather than the presentation. If roles, approvals, price logic or data flows cannot be modelled cleanly in any off-the-shelf system, adapting that system ends up costing more than a custom application. The reverse also holds: for websites and for selling there are TYPO3, WordPress and Shopware 6 — custom development is rarely the cheaper answer there.

What does Symfony have to do with Shopware 6?

Shopware 6 is built on Symfony and adopts its basic principles: dependency injection, events and bundles. For data access, Shopware deliberately goes its own way — instead of the Doctrine ORM there is the Data Abstraction Layer (DAL) with its own entity definitions, repositories and criteria objects. Anyone unaware of that writes code in a Shopware plugin that looks like Symfony and behaves differently. Symfony knowledge remains the prerequisite: everything outside data access follows the framework conventions.

How do Symfony applications stay maintainable in the long run?

A Symfony application stays maintainable through current versions, tests and the absence of workarounds around the framework. We stay on LTS releases, keep dependencies tended with Composer, cover changes with PHPUnit and let PHPStan read along on every commit. Upgrades are prepared with Rector so that a version jump does not turn into a project of its own. Postpone this work for years and you pay for it later as a rewrite.

Symfony: existing system or new build?

We also take over systems that were built elsewhere — after a look at the code and the hosting.

What else we build with

Call Start a project