PRINZIP — MODERN WEB
Modern Web
Oberflächen, die schnell laden und sich in drei Jahren noch warten lassen. Wir wählen Werkzeuge nicht, weil sie neu sind, sondern weil sie ausgereift, breit unterstützt und langfristig pflegbar sind.
Warum wir das so machen
Die Begründung.
Die Kombination aus Next.js, React und TypeScript liefert zwei Dinge gleichzeitig, die sich sonst oft ausschließen: Tempo für den Nutzer und Wartbarkeit für die Entwicklung. Server-seitiges Rendering und statische Generierung sorgen dafür, dass Seiten schnell laden — auch auf schwachen Geräten und langsamen Verbindungen.
Wichtiger als die Werkzeugwahl ist die Zurückhaltung dabei. Jede Abhängigkeit, die man nicht hat, muss man nicht aktualisieren, nicht auf Sicherheitslücken prüfen und nicht mitschleppen, wenn sie irgendwann nicht mehr gepflegt wird. Deshalb prüfen wir bei jedem Paket, ob eine eigene, kleine Lösung dasselbe leistet.
Manchmal ist die richtige Antwort noch weniger Technik: Eine Seite, die nichts nachlädt, kann nichts blockieren. Wie viel eine Aufgabe verträgt, entscheiden wir pro Aufgabe.
Was du davon hast
Deine Nutzer bekommen eine Anwendung, die sich schnell und selbstverständlich anfühlt. Du bekommst eine Codebasis, an der man auch in drei Jahren noch effizient weiterarbeiten kann, statt sie neu schreiben zu müssen — und für die es einen großen Pool an Entwicklern gibt.
Konkret
Die Entscheidungen dahinter.
TypeScript durchgehend, streng eingestellt
Typfehler fallen beim Schreiben auf, nicht beim Nutzer. In den Projekten läuft der Typcheck zusätzlich als eigener Prüfschritt vor jedem Zusammenführen.
Server-first statt Client-Ballast
Was statisch erzeugt werden kann, wird statisch erzeugt. Interaktive Teile bleiben kleine, klar abgegrenzte Inseln statt einer durchgehend clientseitigen Anwendung.
Wenige, bewusste Abhängigkeiten
Jedes Paket muss sich rechtfertigen; was der Browser selbst kann, lösen wir ohne Abhängigkeit. Schriften hosten wir selbst — auch aus Datenschutzgründen.
Design-System statt Einzelstücke
Wiederverwendbare Bausteine und Design-Tokens, damit die zehnte Ansicht so aussieht wie die erste.
Barrierefreiheit als Budget, nicht als Nachtrag
Tastaturbedienung, Fokus-Verhalten, Kontraste und Bewegungsreduktion werden mitgebaut. Das erreicht mehr Menschen und ist in Österreich zunehmend rechtlich relevant.
Belege
Woran du uns messen kannst.
- Das Admin-Panel der RetterApp läuft mit React 19, Vite und Tailwind — mit Datentabellen, Diagrammen, Kommando-Palette und Editor, auf 14 geschützten Seiten (Stand 16.08.2026).
- Beim kompletten Neuaufbau von lebensmittelrettung.at — im gemeinsamen Erscheinungsbild mit der RetterApp — haben wir einen eigenen Bildvergleich gebaut: Screenshots werden pixelweise mit der Design-Vorlage verglichen, Abweichungen als Bilddifferenz abgelegt (Stand 08/2026).
- Die erste Landing-Seite für Lebensmittelrettung Österreich haben wir mit null Zeilen JavaScript gebaut — eine CSS-Datei, Systemschriften, Inline-Grafik (Stand 07/2026; seit 09/2026 vom neuen Internetauftritt abgelöst).
- Auf dieser Website ersetzt ein eigenes Canvas-Partikelsystem eine zuvor eingebaute 3D-Bibliothek, Scroll-Effekte laufen über die CSS-Eigenschaft animation-timeline statt über eine Animationsbibliothek — beides ohne zusätzliches Paket.
Häufige Fragen
Was oft gefragt wird.
Warum nicht einfach ein Baukasten-System?
Für eine reine Visitenkarte ist ein Baukasten oft genau richtig. Sobald aber eigene Abläufe, Rechte oder Datenmodelle dazukommen, kämpft man gegen seine Grenzen an — und zahlt das in Workarounds und Lizenzen. Die Grenze verläuft dort, wo Inhalte aufhören und Logik anfängt.
Wie stellt ihr sicher, dass die Seite auch wirklich schnell ist?
Wir setzen ein Performance-Budget zu Beginn und messen es mit denselben Werkzeugen, die auch Suchmaschinen verwenden. Dazu gehört, Bilder in modernen Formaten auszuliefern und Schriften nicht nachzuladen.
Weiterlesen
Passt dazu.
Die anderen Prinzipien.
Jedes für sich erklärt, warum wir so bauen — und woran man es nachprüfen kann.