Ich baue Software, die echte Probleme löst
Angefangen im eCommerce-Support, heute entwickle ich die Tools, die ich damals selbst gebraucht hätte.
Softwareentwicklung war nie der Plan. Aber wenn du jahrelang im Support für Online-Shops arbeitest und ständig dieselben Probleme siehst, fängst du irgendwann an, sie selbst zu lösen. Und dafür muss man den Code lesen können. Also habe ich es gelernt – mit viel Trial & Error, Learning by Doing und der Hilfe von Stack Overflow. Heute entwickle ich Plugins für OXID 7, Shopware 6 und osTicket, baue Webseiten und Business-Tools mit Symfony – Open Source und kommerziell. Hier erzähle ich dir, wie ich arbeite und warum ich das mache.
Vom Office Manager zum eCommerce-Support zum Entwickler
Ich war eigentlich schon immer ein Office Manager und bin dann in den technischen Support für OXID- und Shopware-Shops "reingerutscht". Später habe ich dann auch noch die Projektleitung für Shopprojekte und Pluginentwicklung übernommen.Dabei habe ich gesehen, was Shop-Betreiber wirklich brauchen und habe angefangen, selbst zu coden. Keine Informatik-Ausbildung, kein Studium. Einfach Learning by Doing, Stack Overflow und viel Trial & Error. Das Kaufmännische liegt mir im Blut, das Technische habe ich mir draufgeschafft.
Womit ich arbeite
Mein Tech-Stack
PHP & Symfony
Modernes PHP 8.2+ mit Symfony ist mein Hauptwerkzeug. Ich mag die klare Struktur, die Symfony erzwingt. Services, Dependency Injection, Events – das ergibt Code, den man auch in zwei Jahren noch versteht.
OXID 7 & Shopware 6
Beide Systeme kenne ich von innen und entwickle Module für sie – alles, was Shop-Betreiber das Leben leichter macht. Entweder im Auftrag oder weil mir selbst die Funktionalität fehlt.
osTicket
osTicket-Plugins sind meine Open Source Projekte, egal ob Markdown-Support, Subticket-Manager, API-Erweiterungen – ich baue das, was im Core fehlt. Signal-basiertes Event-Handling, saubere Architektur, und vor allem: Lösungen, die im Alltag funktionieren.
TypeScript & MCP
MCP-Server in TypeScript für die Integration von Claude Code mit externen Systemen. Wiki.js-Anbindung, osTicket-API – damit KI-Tools auf echte Daten zugreifen können.
Bash & Shell
Automatisierung ist Pflicht. Release-Scripts, Deployment-Workflows, Projekt-Setup – alles, was sich wiederholt, wird gescriptet. Weniger manuelle Arbeit, weniger Fehler.
Wie ich arbeite
Kein Cowboy-Coding. Struktur und Qualität sind nicht verhandelbar.
Test-Driven Development
Tests zuerst, dann der Code. Klingt langsam, ist aber schneller – weil du nicht drei Tage später einen Bug suchst, den du mit einem Test in fünf Minuten gefunden hättest.
Conventional Commits
Jeder Commit erzählt, was passiert ist. feat:, fix:, chore: – damit generiert das Release-Script automatisch den Changelog. Kein manuelles Pflegen, keine vergessenen Einträge.
Claude Code als Werkzeug
Ich nutze Claude Code täglich. Für Code-Reviews, Refactoring-Ideen, Dokumentation. Dafür habe ich eigene Agenten und Skills gebaut, die meine Workflows direkt unterstützen – von der Ticket-Erstellung bis zur Wiki-Dokumentation. Aber: Die KI ist ein Werkzeug, kein Ersatz. Sie macht Routine schneller, das Nachdenken nimmt sie mir nicht ab. Der Code ist meiner, die Verantwortung auch.
Dokumentation
Jedes Projekt wird im Code dokumentiert und erhält zusätzlich noch eine README. Es gibt auch Wiki-Seiten für Endanwender. Code ohne Doku ist nur halb fertig.
Warum ich das mache
- Allem Voran, weil es Spaß macht, Probleme zu lösen und Dinge zu bauen, die anderen helfen.
- Ein gutes Plugin kann hunderten Shop-Betreibern helfen – ohne dass ich jedem einzeln erklären muss, wie es geht.
- Code ist ehrlich. Er funktioniert oder er funktioniert nicht. Keine Politik, keine Ausreden.
Am Ende zählt: Löst die Software ein echtes Problem? Ist der Code sauber genug, dass ich ihn in einem Jahr noch verstehe? Dann war es ein guter Tag.
Projekte ansehen
Schau dir an, woran ich arbeite.