What TYPO3 development looks like in practice
Most enquiries do not start with a technical requirement but with an irritation: content can only be maintained the long way round, a second language does not fit the concept, or a feature exists twice because two extensions are attempting the same thing.
Symptoms like these almost always have the same cause. The installation has grown over years, every requirement was solved on its own, and nobody was given the job of holding the whole thing together. Development then means understanding what is there and deciding what stays.
The sitepackage as the foundation
In TYPO3, everything that makes up the look and structure of a site belongs in an extension of its own. Templates, TypoScript, backend layouts, the configuration of content elements: together they form the sitepackage.
The advantage is unspectacular and decisive. Everything sits in files, files sit in Git, and Git answers the question of why something is the way it is. Configuration that only exists in the database never answers that question.
TYPO3 programming or configuration?
A good many requests for TYPO3 programming can be met without a line of PHP. Large parts of TYPO3 are a configuration system: what a content element can do is described in the TCA, how it is rendered in Fluid and TypoScript. Working there keeps you inside the intended framework and keeps the installation updatable.
Real programming begins where custom data models, business logic or interfaces come into play: a booking process with states, an import that validates and merges data, an evaluation that exists nowhere else. That is where an Extbase extension with model, repository and controller comes in.
The distinction is not hair-splitting; it is the basis of every estimate. Configuration is manageable and easy to change, while custom code wants testing, documentation and attention at every major update. Which of the two categories your requirement falls into is something we tell you up front.
Custom extensions where the standard runs out
TYPO3 brings a lot with it, and the extension repository covers further standard cases. A custom extension is worth it when custom data structures are involved: products with variants, events with registration, locations with opening hours, applications with a file attachment.
We build extensions like these with Extbase, because it produces the backend module, the validation and the frontend output from one data model. It costs a little more care at the start and gives that care back at every later change.
Written with editors in mind
An installation is only finished when the people who work in it every day can work in it. We label fields in the language of the organisation, hide what this particular case does not need, and set defaults so the usual job works without anyone having to think about it.
We show you what that looks like in the backend before handover. If something turns out to be awkward, we change it while changing it is still cheap.