Ich begleite Themen von der Anforderung über Konzept und Umsetzung bis in Betrieb und Support.
Softwareentwicklung
Software beginnt für mich nicht beim Code.
Ich entwickle Lösungen aus konkreten Problemen, Prozessen und Nutzeranforderungen heraus: von der ersten Idee bis in den produktiven Betrieb.
Beruflich arbeite ich seit 2022 als Softwareentwickler und Projektmanager an einer über Jahre gewachsenen, produktiven Webanwendung. Ich bin also kein Entwickler, der Anforderungen nur in Code übersetzt. Zuerst will ich verstehen, welches Problem gelöst werden soll, dann denke ich die Auswirkungen auf das ganze System mit.
Ich übersetze zwischen dem, was Menschen im Alltag brauchen, und dem, was technisch dahinter liegt.
Ich betrachte keine Funktion isoliert, sondern immer im Zusammenhang mit allem, was daran hängt.
Ausgangspunkt
Oft ist nur klar, was besser werden soll.
Ich arbeite nicht ausschließlich nach fertig formulierten technischen Anforderungen. Neue Aufgaben entstehen häufig aus Gesprächen, aus Kundenwünschen, aus Problemen im praktischen Arbeitsalltag, aus Beobachtungen bestehender Prozesse oder aus eigenen Ideen, wie sich das System weiterentwickeln kann.
Wie die technische Lösung aussehen muss, steht am Anfang meist noch nicht fest. Meine Aufgabe ist dann, Informationen zu sammeln, Zusammenhänge zu verstehen, Anforderungen zu hinterfragen und daraus eine sinnvolle Lösung zu entwickeln. Die konkrete Umsetzung entscheide ich dabei weitgehend selbst.
Erst verstehen, dann entwickeln
- Was soll tatsächlich erreicht werden?
- Wie funktioniert der bestehende Prozess?
- Wer arbeitet später mit der Funktion?
- Welche Daten und Systeme hängen daran?
- Welche Folgen kann eine Änderung an anderer Stelle haben?
Eine unscharfe Anforderung ist für mich kein Problem. Aus ihr eine konkrete Lösung zu entwickeln, ist ein Teil meiner Arbeit.
Vorgehen
Wie aus einem Problem eine Lösung wird.
Das ist keine starre Methodik, die ich Schritt für Schritt abarbeite. Es beschreibt eher eine typische Denkweise: welche Fragen ich mir stelle, bevor, während und nachdem etwas gebaut wird.
Was soll tatsächlich erreicht werden, und für wen?
Wie funktioniert der bestehende Prozess, und welche Systeme hängen daran?
Braucht es wirklich eine neue Funktion, oder gibt es einen einfacheren Weg?
Welche Lösung passt zum Gesamtsystem, und nicht nur zum aktuellen Fall?
Backend, Frontend, Daten und Schnittstellen so verbinden, dass es stabil und wartbar bleibt.
Deployment, Beobachtung, Feedback aus der Praxis und daraus die Weiterentwicklung.
Zwischen Nutzer und Technik
Nutzer formulieren selten technische Anforderungen.
Sie beschreiben Probleme, Wünsche und Situationen aus ihrem Arbeitsalltag. Meine Aufgabe ist häufig, daraus eine konkrete technische Lösung abzuleiten. Und genauso oft läuft es in die andere Richtung: Ich übersetze technische Zusammenhänge zurück in eine Sprache, mit der die Menschen etwas anfangen können, die mit der Software arbeiten.
Eine meiner größten Stärken liegt darin, Fachlichkeit, Nutzerperspektive und Softwareentwicklung miteinander zu verbinden. Eine technisch saubere Lösung ist nicht automatisch eine gute Lösung, denn Software wird am Ende von Menschen benutzt. Deshalb gleiche ich technische Konzepte immer mit der tatsächlichen Nutzung ab, bevor ich sie für fertig halte.
Das Gesamtsystem im Blick
Ein Fenster lässt sich austauschen. Das Fundament nicht so leicht.
Ich betrachte Software gern wie ein Haus. Ein kaputtes Fenster ist schnell ersetzt. Kritisch wird es, wenn eine Änderung das Fundament betrifft: Dann kann eine Anpassung an Stelle A an Stelle B ein neues Problem verursachen, an das beim Umbau niemand gedacht hat. Deshalb betrachte ich Funktionen nie isoliert.
Bei jeder Änderung denke ich deshalb mit, was außer der eigentlichen Funktion noch betroffen ist:
Hinterfragen
Nicht jede Anforderung braucht eine neue Funktion.
Eine Anfrage bedeutet nicht automatisch, dass daraus Code werden muss. Jede neue Funktion bleibt: Sie muss gewartet, erklärt und im Support mitgetragen werden. Deshalb prüfe ich eine Anforderung, bevor ich sie umsetze.
- Ist der Bedarf dauerhaft oder nur kurzfristig?
- Wie häufig tritt er tatsächlich auf?
- Gibt es bereits eine Funktion, die das Problem löst?
- Lässt sich der Prozess sinnvoll anpassen?
- Welchen Nutzen bringt die Änderung?
- Welche Komplexität entsteht langfristig, auch für Wartung und Support?
Manchmal ist die beste technische Entscheidung, nichts Neues zu entwickeln.
Aus der Praxis
Drei Beispiele aus meinem Entwicklungsalltag.
Keine Projektberichte, sondern kurze Fälle, an denen sich die Arbeitsweise zeigt. Kundendetails lasse ich dabei bewusst weg.
Schnittstellen
APIs als strategische Grundlage
- Ausgangslage
- Die Anwendung hatte ursprünglich nur wenige und rudimentäre Schnittstellen.
- Überlegung
- Ich habe mich dafür eingesetzt, umfassendere APIs zu entwickeln und das System langfristig stärker über Schnittstellen steuerbar zu machen. Dafür war teilweise Überzeugungsarbeit nötig, weil der direkte Nutzen zunächst nicht immer sichtbar war. Gedacht waren sie für externe Integrationen, Automatisierungen, internen Datenzugriff, KI-Integration und Anwendungsfälle, die es damals noch nicht gab.
- Ergebnis
- Heute lassen sich diese Schnittstellen für Automatisierungen und externe Systeme nutzen. Auch neue Entwicklungen wie ein eigener MCP-Server können auf dieser Grundlage aufbauen, statt bei null anzufangen.
- Prinzip
- Nicht nur den aktuellen Anwendungsfall entwickeln, sondern tragfähige technische Grundlagen schaffen.
Bedienung
Terminfilter vereinfachen
- Ausgangslage
- Ein Bereich im System sollte für Nutzer einfacher werden.
- Überlegung
- Einige der vorhandenen Filter hatten ohnehin nur eine mögliche Auswahl. Ein Filter mit nur einem Wert bringt niemandem einen Mehrwert.
- Lösung
- Solche Filter werden ausgeblendet.
- Prinzip
- Komplexität reduzieren, statt neue Funktionen hinzuzufügen. Besser heißt nicht automatisch mehr.
Fachlichkeit
Preisstrukturen verständlich machen
- Ausgangslage
- Die Verwaltung von Preisen braucht fachlich Konzepte wie Preislevel, Kategorien und Profile. Die Struktur ist sinnvoll, für Nutzer aber nicht automatisch intuitiv.
- Überlegung
- Eine logische Datenstruktur kann in der Bedienung unnötig kompliziert wirken.
- Lösung
- Die Fachlichkeit bleibt erhalten, die Oberfläche macht sie über eine passende Matrix zugänglich.
- Prinzip
- Fachlichkeit nicht verbiegen, sondern verständlich zugänglich machen.
Verantwortung
End-to-End-Verantwortung im eigenen Entwicklungsbereich.
In meinem Entwicklungsbereich arbeite ich weitgehend eigenständig und begleite Software über den gesamten Lebenszyklus. Dazu gehören Gespräche mit Nutzern und Kunden genauso wie Datenbankdesign, API-Entwicklung, die Integration externer Systeme, Performance- und Fehleranalyse. Sicherheit gehört dabei selbstverständlich zu den Themen, die ich berücksichtige.
- Anforderung
- Konzept
- Datenmodell
- Backend
- Frontend
- Schnittstellen
- Deployment
- Betrieb
- Support
Für mich endet eine Funktion nicht mit dem Deployment. Danach beobachte ich ihr Verhalten, achte auf Fehler, hole bei Bedarf gezielt Feedback von Nutzern ein und prüfe, ob sie im Alltag tatsächlich funktioniert. Viele Verbesserungen entstehen erst durch die echte Nutzung und fließen dann in die Weiterentwicklung zurück.
Die Anwendung selbst ist über Jahre gewachsen: mehrere hunderttausend Zeilen Code, knapp 100 Datenbanktabellen und mehrere hundert API-Endpunkte. Zur Einordnung vier Zahlen:
285.000
Zeilen Code in PHP, Vue und Blade, gerundet
93
Datenbanktabellen
467
API-Routen
2.200
Dateien im Repository, gerundet
Gezählt im Repository der Anwendung, Stand 09/2026.
Prinzipien
Woran ich eine gute Lösung messe.
Eine Funktion soll mit unterschiedlichen Daten, Nutzern und Situationen umgehen können, nicht nur mit dem einen Spezialfall, für den sie angefragt wurde.
Eine Verbesserung an einer Stelle darf an anderer Stelle keine neuen Probleme erzeugen.
Technisch nachvollziehbar heißt nicht automatisch intuitiv.
Schnittstellen ermöglichen Integration, Automatisierung und Weiterentwicklung, auch für Fälle, die heute noch niemand kennt.
Die technisch spannendste Lösung ist nicht automatisch die beste. Entscheidend ist, was im Alltag trägt.
Software muss sich im realen Einsatz bewähren. Erst dort zeigt sich, ob eine Lösung gut war.
Werkzeuge
Technologien sind Werkzeuge, keine Identität.
Aktueller Stack
Womit ich derzeit hauptsächlich arbeite
Welche Technologie sinnvoll ist, ergibt sich aus dem Problem, dem Bestandssystem und den Anforderungen. Ich bin technisch neugierig und arbeite mich gern in Neues ein. Festgelegt auf einen Stack bin ich deshalb nicht.
KI in der Entwicklung
Claude Code als Teil des Workflows
Seit 2026 ist Claude Code ein fester Bestandteil meiner Entwicklung. Es hilft mir, eine große, gewachsene Codebasis schneller zu durchdringen, Probleme zu analysieren und Umsetzungen auszuarbeiten.
Die Entscheidungen über Fachlichkeit, Architektur und Umsetzung bleiben bei mir. KI ist ein Werkzeug innerhalb des Entwicklungsprozesses, kein Ersatz für ihn. Wie ich Claude Code einsetze, steht auf einer eigenen Seite.
Weiterlesen
Dieselbe Arbeitsweise, andere Einsatzfelder.
Systeme verstehen, Daten verbinden, wiederkehrende Probleme erkennen und Abläufe vereinfachen: Das mache ich nicht nur beruflich. Privat steckt dieselbe Denkweise in meinem Smart Home, in meinen n8n-Automationen und im Homelab. Wie ich dorthin gekommen bin, erzählt meine Laufbahn.