TYPO3 Is More Than a CMS
Building business applications with the TYPO3 backend.
I only want to offer a different view.
Sometimes to look at a problem from a different angle helps to find a solution.
Last Christmas…
…I decided to spend the winter break vibecoding — building our own ERP, time-tracking and “everything” app.
With a real project, not a tutorial.
I did not sit down to write a talk.
I sat down because something at work had been annoying me for a very long time.
A system that stopped following us.
We ran a normal ERP. Over the years our processes changed, and it did not. Answers took long, changes never came, and the reports we needed were very hard to get.
Then, that December, I simply could not reach them at all. That was the moment I stopped waiting.
The developer in me — and the CEO in me.
The developer wants: control over the code, focus on the application logic, and a tested, secure framework that stays easy to use.
The CEO wants: quick results, fewer licence costs, no time wasted on trivial plumbing — just create value.
“This already exists in TYPO3.”
My first instinct was Symfony — it is excellent, and TYPO3 uses many of its components. This is not a Symfony-versus-TYPO3 fight. But every capability I listed — admin interface, users & permissions, module navigation, record editing, lists, scheduled tasks, logging, dashboards — brought the same sentence back.
Why rebuild what I already have, already tested, and already know?
And what would you even build it with?
The assistant that writes it — Gemini, Claude, ChatGPT, Kimi?
The framework underneath — Symfony, .NET, React?
Imagine TYPO3 is not “just” a CMS, but a framework for applications.
Imagine TYPO3 with no content. No pages. No content elements. No website.
What is left?
If the answer is “nothing,” this talk is over in two minutes. So instead of guessing, let us look at how TYPO3 is actually assembled — Composer already tells us most of the answer.
Where the pieces actually live.
Modern TYPO3 is a set of Composer packages. Pages live deep in the core; tt_content — the content elements — come from the frontend package. Content is a frontend concern; pages are a core concern. So the frontend is the part we can take away.
Yes
Technically, nothing fundamental depends on it. The dependency runs the other way — the frontend depends on the core, not the core on the frontend. This is not a hack; it is the architecture working as designed.
Plenty of things use it.
# the foundation does not need the frontend —
# but a lot of code around it assumes it is there.
RuntimeException: No site configuration found for request
TypeError: a rendering context was expected
Error: a page id is required (pid)…
Two things are true at once: TYPO3 has a powerful backend platform that does not require the frontend — and it is not (yet) designed as a first-class backend-only product. Not broken; used outside its primary use case.
Things you get out of the box with the TYPO3 backend.
These are the things you don't need to spend a dime on — covered by the framework, tested and secure.
Identity & access.
A business application needs to know who you are and what you may see and change. I did not invent an auth layer — I extended one reviewed by many people over many years.
TCA turns a data structure into a usable backend.
Describe a table with TCA, and the FormEngine produces a working editing interface — plus the record list for any table. Honest warning: this does not remove the need for UX design. But the difference between thinking about a form and building a form framework is enormous.
Work happens while nobody is watching.
Imports at night. A reaction when money arrives. A notification to another system. The scheduling and its administration already exist. And a new module is not a new architecture — a controller, a repository, a Fluid template, a TCA definition. Everything else is decided.
The technical background.
Nobody demos logging. But when something breaks in production at seven in the morning, this is the layer you reach for — and it was there on day one.
The application foundation already exists.
TYPO3 lets us start closer to the business problem. Four layers of foundation, one thin layer on top — and that thin layer is the only part that is actually about my business.
DigiTrack — running on TYPO3 14.
No website. No content elements. Just the backend. Not a conference prototype — we run our company on it. Everything familiar came from TYPO3; everything unfamiliar is our business.
The backend is the whole application.
Built from TYPO3 packages.
Controllers do not query the database — business logic lives in services, data access in repositories. That is why the codebase is still understandable after a year of fast changes.
Now the practical part.
One blocker. One workaround. Three ideas.
pid
Stored as a parent id. Treated as a page id. Permissions, the page tree, the module context — all assume it. So an application with no pages grinds on this one field. pid is not wrong; it is right for a CMS.
The boundary is the organisation, not the page.
record.pid = 0 # no page, no tree
record.organisation = currentOrganisation # applied on save by a DataHandler hook
# every read & write is scoped to the organisation — a developer cannot forget it.
Everything is saved outside the page tree. Ownership moves to our own context: in a CMS the boundary is the page — in DigiTrack it is the organisation. It is a workaround, and I will call it one. But it is small and contained.
Three things we built for the backend.
1. Backend User invite — a small extension we're publishing: invite editors by email and pick their groups, instead of hand-crafting accounts.
2. Sortable list columns — not just choosing which columns show, but sorting by them. A better view on the data.
3. List-view filters — a TCA-based way to define filters and apply them right in the list view.
Speed cuts both ways.
AI and coding agents let me build more code in less time. But it is now very easy to produce code that is inconsistent, unsafe, or unmaintainable — generated code does not come with a security model. The consequences of a weak foundation are still expensive.
A good foundation turns development speed into value.
Development is becoming less expensive, so more internal tools become possible. And because we can build more, the quality of the foundation matters more, not less.
The licence saving was not the biggest win.
What if the TYPO3 backend is your application framework?
Remove the website, and a surprisingly complete foundation remains. TYPO3 will remain a CMS — that is its strength. But perhaps we can stop seeing the backend only as where editors manage websites.
What would you build with it?
Thank you.