What we use TYPO3 for
TYPO3 comes into play with us when a website is more complicated organisationally than technically. A group with several brands, a public authority with departments, an association with regional chapters: each unit maintains its own area, and none should be able to change anything in anyone else's. TYPO3's permission system is built for that, with backend user groups, page permissions and separate file mounts. In a WordPress setup the same requirement regularly ends in a collection of role plugins.
The second classic is multilingualism. Not “translation switched on”, but separate language trees, fallback rules, country-specific content and editorial teams working in different languages. Then there are sites with many pages that have grown over years, where nobody holds the full structure in their head any more. TYPO3 copes with structures like that, as long as templates and extensions stay cleanly separated. We plan accessibility to BITV (the German accessibility regulation for public-sector information technology) and EN 301 549 in from the start.
How we work with TYPO3
A TYPO3 project here consists of site configuration, TypoScript, Fluid templates and a handful of custom extensions in PHP. Configuration lives in files and therefore in version control, not scattered across the backend. We manage the installation and the extensions with Composer, and deployments run through a staging instance. We build content elements with Content Blocks or our own data structures rather than with generic construction-kit elements, so that editors can see what they are maintaining instead of guessing.
The recurring type of project is the upgrade. Sites on v8 to v12 come to us because support has run out or because PHP on the server has to be updated. We look at the extensions first: what has been absorbed into the core, what only exists as an unmaintained third-party extension, what was never needed anyway. After that the installation is pulled up in steps across the LTS versions, not in one jump to v14.
Limits: when TYPO3 is too much
TYPO3 has a learning curve, in the backend as much as in development. For a company website with a manageable number of pages, one language and one editor who posts a news item now and then, the system is oversized. There we recommend WordPress with a custom theme — quicker to build, and in daily use closer to what such teams expect. We do not sell anyone an editorial system they then avoid because the backend puts them off.
The second limit is the shop. TYPO3 has shop extensions, but a sales process with price rules, payment methods, returns and an ERP connection belongs in a shop system. When a TYPO3 site is meant to sell, we pair it with Shopware 6 instead of forcing the shop into the CMS. The reverse holds too: anyone who needs a pure campaign one-pager gets no TYPO3 instance with an editorial workflow from us, but something that can be switched off again without effort.