Technik
Womit wir bauen – und warum ausgerechnet damit
Technikentscheidungen sind Geschäftsentscheidungen: Sie bestimmen, wie schnell Ihre Seite lädt, wie teuer eine Änderung in drei Jahren ist und ob Sie den Dienstleister wechseln können. Deshalb legen wir sie offen.
Statisch ausliefern, dynamisch entwickeln
Jede Seite wird beim Bauen einmal fertig gerendert und danach als reine HTML-Datei ausgeliefert. Für den Besucher heißt das: keine Datenbankabfrage, kein Serverrechnen, sichtbarer Inhalt in Sekundenbruchteilen. Für Suchmaschinen heißt es: alles steht im Quelltext, auch ohne JavaScript. Und für die Sicherheit heißt es, dass ein ganzer Typ von Schwachstellen gar nicht greift: Wo kein PHP und keine Datenbank im Auslieferungsweg liegen, läuft eine Lücke darin ins Leere. Angriffsfläche bleibt dort, wo Logik läuft – beim Formularversand –, und die halten wir klein und aktuell.
React, weil es Bestand hat
React ist seit über zehn Jahren im Einsatz, wird von einer großen Zahl Entwickler beherrscht und ist gut dokumentiert. Wer Ihr Projekt später übernimmt, muss nichts Exotisches lernen. Dasselbe gilt für Node.js auf der Serverseite.
Eine Quelle für SEO-Angaben
Titel, Beschreibungen, strukturierte Daten, Sitemap und Canonical entstehen aus einer einzigen Datei im Projekt. Damit kann eine Seite gar nicht erst vergessen werden – und niemand muss in einem Plugin-Menü nachpflegen.
Nach dem Start wird gemessen
Eine Seite ist mit dem Livegang nicht fertig, sondern messbar. Über die Google Search Console sehen wir je Seite, zu welchen Suchanfragen sie erscheint, auf welcher Position sie steht und wie oft geklickt wird. Das ist die Grundlage für Anpassungen an Überschriften, Texten und Struktur – und der Unterschied zwischen Optimierung und Vermutung.
Keine fremden Server, wo keine nötig sind
Schriften, Symbole und Bilder liegen auf demselben Server wie die Seite – der häufigste Datenschutzmangel auf deutschen Firmenwebsites ist die von Google nachgeladene Schriftart. Beim Aufruf einer von uns gebauten Seite entsteht deshalb keine Verbindung zu einem fremden Anbieter. Davon zu unterscheiden ist die Frage, wo die Seite selbst betrieben wird: Das sind etablierte Plattformen, teils von US-Unternehmen, betrieben in europäischen Regionen – wir benennen sie, statt mit einem Serverstandort zu werben, den wir nicht überall einhalten könnten.
Barrierefreiheit ist Handwerk, kein Modul
Farbkontraste werden ausgerechnet, nicht geschätzt. Alles ist mit der Tastatur bedienbar, Überschriften folgen einer Ebene, Animationen halten sich an die Systemeinstellung für reduzierte Bewegung. Ein Overlay-Werkzeug, das Barrierefreiheit „nachrüstet", setzen wir nicht ein – es löst die Probleme nicht.
Alles liegt in GitHub
Jede Zeile Code, jede Anforderung und jede Entscheidung landet in einem Repository mit Historie. Das klingt nach Entwickler-Kleinkram, hat aber handfeste Folgen: Änderungen sind nachvollziehbar, ein fehlerhafter Stand lässt sich zurückrollen, und eine Erweiterung in drei Jahren braucht kein Rätselraten. Der Zugang gehört Ihnen – auch wenn Sie später mit jemand anderem weiterarbeiten.
Dokumentation als Textdateien
Projektwissen landet bei uns in Markdown – gewöhnlichen Textdateien neben dem Code. Das ist unspektakulär und genau deshalb richtig: Markdown lässt sich versionieren, zeigt Unterschiede zwischen zwei Ständen, ist ohne Spezialsoftware lesbar und läuft nicht Gefahr, mit einem Werkzeug zu verschwinden. Entscheidungen stehen dort mit Begründung, nicht nur als Ergebnis.
Datenbanken sind Handwerk
Die meisten Anwendungen stehen und fallen mit ihrem Datenmodell. Wir arbeiten mit PostgreSQL, Microsoft SQL Server und MySQL, übernehmen gewachsene Bestände und schneiden die Struktur neu, wenn sich damit halbe Programmierarbeit sparen lässt. Was zuvor in verteilten Tabellen lag, wird dabei zu etwas, das Auswertungen und mehrere Nutzer gleichzeitig aushält.
KI dort, wo sie trägt
Sprachmodelle sind gut im Formulieren und Einordnen, schlecht im Erfinden von Fakten. Deshalb hängen unsere Assistenten an Ihren Daten und nennen ihre Quelle, und Agenten bekommen genau die Werkzeuge, die sie brauchen – mit Protokoll und menschlicher Bestätigung vor allem, was nach außen wirkt.
Grenzen
Für Shops mit Lager, Zahlung und Retouren sind erprobte Standardsysteme fast immer die bessere Wahl; wir sagen das, statt einen Shop nachzubauen. Native Apps für App Store und Play Store machen wir nicht – wohl aber installierbare Webanwendungen, die auf dem Startbildschirm liegen.
Werkzeugkasten
Nicht jedes Projekt braucht alles. Was zum Einsatz kommt, steht im Angebot – inklusive der Frage, wer es später betreibt.
React
Oberflächen und Anwendungen
Vite
Build und Entwicklung
Tailwind CSS
Gestaltung ohne CSS-Wildwuchs
Node.js
Serverseitige Logik und Schnittstellen
PostgreSQL
Datenhaltung, Volltext, Auswertungen
Microsoft SQL Server
Bestandssysteme und Ablösung
MySQL / MariaDB
Verbreitete Bestände, Migration
Git & GitHub
Versionen, Anforderungen, Übergabe
Docker
Reproduzierbarer Serverbetrieb
LLM-Schnittstellen
Assistenten und Agenten
ESP32 & FreeRTOS
IoT-Module mit Sensorik und Display
Angular
Bestandsprojekte und Wartung
Diese Seite ist das Muster
Was hier über Tempo, Datenschutz und Struktur steht, gilt für die Seite, auf der Sie gerade sind: statisch vorgerendert, Schriften vom eigenen Server, keine Cookies, keine Zählpixel, Struktur und Texte im Quelltext. Prüfen Sie es nach – der Quelltext ist einsehbar, die Ladezeit messbar.
HTML im Quelltext
Inhalt auch ohne JavaScript vollständig
Schriften self-hosted
Zwei Variable Fonts, zusammen unter 80 KB
Keine Cookies
Nur ein lokaler Eintrag, wenn Sie den Hinweis schließen
Dunkelmodus
Folgt der Systemeinstellung, ohne zweite Gestaltung
Erzählen Sie von Ihrem Vorhaben.
Im Erstgespräch klären wir, was sinnvoll ist und was es kostet – kostenlos und ohne Verpflichtung. Auch dann, wenn am Ende ein fertiges Produkt die bessere Antwort ist.