Mechanical engineering needs product data, not prose
The mid-sized economy on the Danube lives on products that need explaining: variants, technical data, data sheets, often in several languages. Content like that rarely belongs typed into the CMS; it comes from an ERP or a PIM and should stay maintained there.
TYPO3 is well set up for this case: custom data models through Extbase, interfaces to existing systems, and output that can be shaped freely. What we settle early: what happens when the other side does not answer? Defined behaviour when something fails matters more than the fastest import.
Proximity you notice
Stuttgart to Ulm is around an hour. That sounds mundane and it changes something in daily project work: a meeting at short notice is possible without anybody losing half a day. We use that gladly for kick-offs, workshops and training.
When the installation is older than the last relaunch
Many sites in the region are soundly built and have simply aged: the version is running out of support, some of the extensions are abandoned. The route from there is almost always the same: an inventory, then the honest decision between an update and a relaunch, then orderly implementation.
Interfaces are the real core of the project
For machine builders, a website project is rarely decided on the design but on the question of how product data reaches the page. Variants, characteristics, data sheets, often in several languages: all of it originates in the ERP or the PIM and should stay there.
For TYPO3 that means custom data models through Extbase, an interface that recognises changes, and output that can be shaped freely. The effort sits less in the import than in the edge cases. What happens when the other side does not answer? Which side counts as the truth when both have been changed? We settle those questions before the implementation, not during operation.
When data should arrive regularly
An import somebody triggers by hand gets forgotten eventually. So tasks like that run through the scheduler: scheduled, logged and without anyone doing it.
The catch is well known and still widespread: the scheduler does not start itself. If the cron job on the server is missing or went astray during a move, the tasks do not run, and nobody notices because everything looks right in the backend.
So for anything somebody relies on we set up an alert that fires when execution stops as well. Watching only for errors is not enough: a task that no longer starts does not report an error either.