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. Genau hier beginnt für mich die Anforderungsanalyse: Informationen sammeln, Zusammenhänge verstehen, Anforderungen hinterfragen und daraus eine sinnvolle Lösung 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
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. Ein Beispiel ist n8n, das ich im Unternehmen eingeführt habe und das dort inzwischen eine tragende Säule bei der Automatisierung wiederkehrender Aufgaben ist. Überall, wo ein Workflow Daten aus dem System braucht, greift er über diese Schnittstellen zu.
- Prinzip
- Nicht nur den aktuellen Anwendungsfall entwickeln, sondern tragfähige technische Grundlagen schaffen.
Planung
Passkeys anbinden: erst der Plan, dann der Code
- Ausgangslage
- Nutzer sollten sich mit Passkeys an der Anwendung anmelden können. Eine Änderung, die an mehreren Stellen eingreift und bei der ich nicht erst hinterher merken wollte, wie sie gedacht ist.
- Überlegung
- Bevor eine Zeile Code entstand, habe ich mit Claude Code im Plan Mode einen Plan erarbeitet, auch darüber, wo die Verknüpfung zu finden sein soll. Dafür habe ich mir 30 bis 60 Minuten genommen.
- Ergebnis
- Ich konnte vorab sehen, wie die Umsetzung aussehen soll, und an einer Stelle gegensteuern. Die Korrektur traf einen Absatz im Plan statt fertigen Code.
- Prinzip
- Bei Änderungen, die an mehreren Stellen eingreifen, die Details klären, bevor Code existiert.
Fachlichkeit
Saalpläne aus jeder Vorlage ins System bringen
- Ausgangslage
- Saalpläne kommen in den unterschiedlichsten Formen an: als Excel-Tabelle, als Bild, als PDF oder als rohe SVG-Datei. Ins System müssen sie in einer einheitlichen Struktur. Bisher habe ich jeden Saalplan von Hand in Canva nachgebaut und als SVG exportiert, ein enormer Aufwand.
- Lösung
- Der Weg läuft in zwei Schritten über Claude Code: Aus der Vorlage entsteht zuerst ein SVG-Saalplan, aus diesem dann die Einträge für die Datenbank.
- Prinzip
- Uneinheitliche Eingaben zuerst in ein einheitliches Format bringen, bevor sie ins System gehen.
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 Full-Stack: Datenbank, Backend, Schnittstellen und Frontend liegen in einer Hand, und ich 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.
Planung und Qualität
Festhalten, einschätzen, prüfen.
Neben der Entwicklung bin ich in meinem Bereich auch Projektmanager. Damit Planung und Prüfung nicht davon abhängen, wie viel Zeit gerade ist, haben Issues und Pull Requests bei mir eine feste Form.
Issues
Bugs als strukturierte Issues
Fällt mir beim Arbeiten mit Claude Code etwas auf, legen wir das Issue direkt in der Sitzung an, ohne sie zu verlassen. Jedes Issue hat denselben Aufbau: Problem, Auswirkungen, ergänzende Informationen, Zielzustand nach dem Bugfix und ein geschätzter Aufwand in Stunden. Fehlen Kerninformationen, stehen sie als Rückfrage im Issue.
Pull Requests
Änderungen mit Aufwand und Risiko einschätzen
Pull Requests lasse ich einzeln oder für einen Zeitraum zusammenfassen: die Änderungen nach Frontend, Backend und Infrastruktur gruppiert, der Aufwand als Stundenschätzung mit Konfidenz, dazu markierte Lücken bei Tests, Migrationen und Security. Das ergibt eine einheitliche Grundlage für Priorisierung und Abstimmung.
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.
Nachprüfbar
Ein Projekt, das jeder prüfen kann: diese Website.
Was ich beruflich baue, ist nicht öffentlich. Diese Website schon. Sie entsteht im Dialog mit KI, überwiegend mit Claude Code, und folgt denselben Regeln, die ich auch sonst an Software anlege.
- Statisches HTML pro Seite, ein Stylesheet, ein Skript. Kein Framework, kein Build-Schritt.
- Keine Anfragen an fremde Server: keine CDNs, keine Schriftdienste, keine Zählpixel.
- Ohne JavaScript bleibt alles lesbar.
- Nichts springt beim Laden: Der Platz für Nachgeladenes ist reserviert.
- Messskripte halten die Zahlen auf der Seite aktuell.
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: für neue Features und Bugfixes, beim Debugging und beim Anlegen von Issues. 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 das konkret aussieht, beschreibe ich unter KI-gestützte Softwareentwicklung mit Claude Code. Wann ich vorher plane, steht auf der Seite zum Plan Mode, und welche wiederkehrenden Abläufe ich festhalte, auf der Seite zu den Skills.
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.