Wie ich bei sentin mit React-Architekturen arbeite – und was ich daraus mitnehme

Seit einiger Zeit arbeite ich als Software Engineer (React Full Stack) bei der sentin GmbH – einem Unternehmen, das KI und Automation für zerstörungsfreie Werkstoffprüfung (NDT) entwickelt. Was ich dort tagtäglich mache, hat meine Arbeit als Engineer geprägt – und zwar in eine Richtung, die ich vorher so nicht erwartet hätte.

Der Stack

Bei sentin arbeite ich mit einem breiten Spektrum:

• React & Vite für modulare Frontend-Architekturen
• TypeScript für Typsicherheit und Wartbarkeit
• Electron.js für Desktop-Komponenten
• Vue in Teilbereichen, wo es den Stack sinnvoll ergänzt

Nichts Exotisches, eher bewährte Technologien, die auf jedem Arbeitslaptop laufen und gewartet werden können. Und das ist auch der Plan.

Was ich gelernt habe: Nutzer nicht überschätzen

Das klingt erstmal negativ. Ist es aber nicht. Es ist eine der wertvollsten Lektionen meiner Arbeit:

> Viele Nutzer sind keine Techniker. Sie haben nichts mit Hardware oder Software am Hut. Und sie wollen es auch nicht lernen.

Das ist kein Vorwurf – es ist einfach Realität. Ein Prüfingenieur, der täglich mit Software aus den 2000ern arbeitet, hat kein Interesse daran, sich in eine komplexe moderne UI einzuarbeiten. Er will seine Arbeit erledigen – und zwar schnell, zuverlässig und ohne Frust.

Die Konsequenz: Intuitiv ist kein Nice-to-have, sondern Pflicht

Ich habe gelernt, alles, was ich bei sentin entwickle, intuitiv und verständlich aufzubauen. Konkret bedeutet das:

• Weniger ist mehr: Jeder Button, jeder Screen wird hinterfragt. Braucht der Anwender das wirklich?
• Domänensprache statt Fachbegriffe: Kein Entwickler-Jargon im UI. Die Software spricht die Sprache der Anwender.
• Schlanke Komplexität: Die Technik im Hintergrund darf komplex sein. Das UI nie.

Das Ziel: Auch jemand, der mit einer Software aus dem Jahr 2000 arbeitet, soll sich 2026 in unserer Software zurechtfinden und sich fragen: „Warum kann das nicht jeder so?"

Was ich daraus mitnehme

Diese Erfahrung hat auch meine eigene Webentwicklung fundamental beeinflusst. Wenn ich heute an einem Produkt arbeite – angestellt oder in eigenen Freelance-Projekten –, sind das meine ersten drei Fragen:

1. Wer ist der tatsächliche Endanwender? Nicht der Entscheider, der den Vertrag unterschreibt, sondern die Person, die täglich damit arbeitet.
2. Wie viel Zeit habe ich investiert, um diese Person zu verstehen? Nicht nur ihre Aufgaben, sondern ihre Frustrationen mit aktuellen Tools.
3. Wann habe ich zuletzt einen Nicht-Techniker vor die Software gesetzt und ihn einfach machen lassen?

Die meisten Teams scheitern nicht an der Technik. Sie scheitern daran, dass sie für sich selbst entwickeln, statt für den Menschen am anderen Ende.

Fazit

Bei sentin baue ich Software, die funktioniert und die jeder bedienen kann. Das ist kein Widerspruch zu guter Architektur. Im Gegenteil: Die beste Architektur ist die, die im Hintergrund alles richtig macht, damit der Anwender vorne nichts davon merken muss.

Für meine eigenen Projekte nehme ich genau dieses Mindset mit: Verstehe, wer vor deinem Produkt sitzt.