Produkte, die Sie verstehen können. Systeme, auf denen wir aufbauen können.

Was zu lösen war

Ein medizinisches Zentrum mit einem Verzeichnis von Hunderten tarifierter Leistungen brauchte für jede Leistung eine eigene Seite, in der Suche auffindbar, mit Preis und Maßeinheit — nicht ein PDF mit der Preisliste. Außerdem ändern sich Preise und Team, also musste die Klinik sie selbst bearbeiten können, und die Terminvereinbarungen mussten sofort bei der Rezeption ankommen, nicht in einem E-Mail-Postfach.

Was wir gebaut haben

Next.js 14.2.35 (App Router) mit React 18, TypeScript und Tailwind. Jeder Eintrag aus dem medizinischen Verzeichnis wurde zu einer eigenen statischen Route: 521 `page.tsx`-Dateien in `src/app`, davon 481 unter `/servicii` — 184 Physiotherapie, 122 Beratungsleistungen, 61 periodische medizinische Untersuchungen, 27 Gynäkologie, 26 Ozontherapie, 23 Behandlungspakete, 18 Alternativmedizin, 12 Diagnostik, der Rest nach Abteilungen. Die Sitemap auf der Produktionsumgebung listet 890 Adressen. Die Website ist zweisprachig ro/ru. Der editierbare Inhalt (Ärzte, Pakete, Behandlungen, Artikel, Einstellungen, Bilder) liegt in einer lokalen SQLite-Datenbank mit `better-sqlite3`, mit WAL-Journal und aktiven Fremdschlüsseln, verwaltet aus `/admin` über 20 API-Routen; die Authentifizierung verwendet `jose` für die Sitzung und `bcryptjs` für das Passwort, und beim Ändern des Passworts werden bestehende Sitzungen ungültig. Die Formulare für Terminvereinbarung und Kontakt werden mit `zod` + `react-hook-form` validiert und senden die formatierte Nachricht direkt über die Bot API an Telegram. Es gibt auch einen Preisrechner auf `calculator`.

Was zu lösen war

Das Menü eines Clubs ändert sich oft, hat Preise und Volumen, die genau sein müssen, und wird auf dem Telefon im Dunkeln von Menschen gelesen, die drei Sprachen sprechen. Ein gescanntes PDF auf einem QR-Code löst davon nichts: Es ist nicht durchsuchbar, nicht übersetzbar und nicht aktualisierbar, ohne den Code neu zu drucken.

Was wir gebaut haben

Ein digitales Menü ohne Arbeitsrahmen und ohne Pakete: Die echten Quellen sind vier JSON-Dateien, und ein Python-Generator mit 402 Zeilen schreibt daraus eine einzige `index.html`. 119 Produkte in 21 Kategorien, jedes mit Preis, Volumen, Zusammensetzung und Foto; 119 kurze Vorstellungstexte, je einer pro Produkt; 119 Sätze mit Kombinationshinweisen („womit es passt“), die der Besucher auf jeder Karte sieht. Das Menü hat drei Sprachen: Rumänisch ist die Basis, und Russisch sowie Englisch decken nicht nur die Oberfläche ab, sondern auch die Kategorien, Volumen, Zusammensetzungen, die 82 Geschmacks-Tags und alle 119 Vorstellungstexte. Warenkorb, Favoritenliste und Rechnungsteilung laufen im Browser, ohne Konto und ohne Server. Die Schriftarten werden auf derselben Domain gehostet, nicht bei Google. Vor jeder Veröffentlichung läuft ein Skript mit 233 Zeilen und 16 Prüfungen — dass kein Tracker hineingeraten ist, dass nichts von einer Dritt-Domain angefordert wird, dass JSON gültig ist und jedes Bild existiert, dass das Menü in allen drei Sprachen vollständig ist, dass die Preise in jeder Kategorie absteigen und dass die strukturierten Daten auf der Seite gültig sind. Die Veröffentlichung erfolgt automatisch über GitHub Actions bei der Zusammenführung in `main`, nachdem der Workflow eine vollständige Kopie der Produktion erstellt und 30 Tage aufbewahrt.

Was zu lösen war

Eine Gemeindeverwaltung muss gemäß HG 728/2023 eine offizielle Website haben — mit festen Bereichen (Entscheidungstransparenz, Projekte und Beschlüsse, Mitteilungen, Dokumente, Kontakte, Haushalt) — und sie selbst aktualisieren können, ohne bei jeder Mitteilung einen Entwickler zu brauchen. Ohne das bleibt öffentlich relevantes Informationsmaterial auf Papier oder in einer Facebook-Gruppe.

Was wir gebaut haben

Laravel 12 Anwendung auf PHP 8.2 mit MySQL 8, Frontend Vite + Tailwind, verpackt in zwei Docker-Containern (`japca_app` = nginx + PHP-FPM, `japca_db` = MySQL). Die Architektur trennt absichtlich zwei Arten von Inhalten: den redaktionellen, der sich selten ändert (Geografie, Geschichte, Institutionen, Kontakte, Budget), in einer einzigen PHP-Konfigurationsdatei mit 1613 Zeilen, die die Blade-Templates direkt lesen, und den häufig ändernden (Ankündigungen, Fotogalerie, Projekte und Beschlüsse, Dokumente, Transparenzeinstellungen) in MySQL, der im Panel `/admin` bearbeitet wird. 40 Blade-Templates, 32 Routen, 10 Datenbank-Migrationen. Die Anmeldung im Panel ist auf 5 Anfragen pro Minute von derselben Adresse begrenzt — die sechste erhält 429 — und jede Verwaltungsaktion wird in eine Audit-Tabelle eingetragen. Die Sicherheitsheader und die Sitemap sind durch automatisierte Tests abgedeckt, die in CI laufen.

Was zu lösen war

Dasselbe wie bei jedem QR-Code-Menü: Es muss auf dem Telefon schnell sein, preislich korrekt, in drei Sprachen lesbar und in fünf Minuten änderbar, wenn die Küche ein Gericht streicht. Außerdem braucht das Restaurant keinerlei Kundenverfolgung — und dann ist die eigentliche Frage, ob jemand wirklich eine Website baut, die nichts sammelt, oder das nur in die Datenschutzrichtlinie schreibt.

Was wir gebaut haben

Eine einzige `index.html`, generiert von einem 377-zeiligen Python-Skript aus JSON-Dateien: 146 Produkte in 31 Kategorien, 143 kurze Vorstellungstexte, plus die Übersetzungen ins Russische und Englische für Kategorien, Namen, Volumen, Zusammensetzungen, Etiketten und Texte. Warenkorb, Favoritenliste und Rechnungsteilung laufen im Browser. Die Website wird direkt von Caddy 2 mit automatischem HTTPS ausgeliefert. Das Interessante ist, dass die Nichtverfolgung der Nutzer keine Zusage ist, sondern eine durch die kontinuierliche Integration erzwungene Regel: Bei jedem Pull Request regeneriert CI `index.html` aus den Quellen und lehnt den PR ab, wenn das Ergebnis von der Datei im Repo abweicht (also entspricht die veröffentlichte Seite immer den Quellen), dann laufen 14 Prüfungen — keine Tracker, keine automatisch von einer Dritt-Domain geladene Ressource, lokal gehostete Fonts, keine Backup-Dateien im Repo, Datenschutzrichtlinie vorhanden und aus der Fußzeile verlinkt, vollständiges Menü in drei Sprachen, Preise in jeder Kategorie absteigend sortiert, gültige strukturierte Daten — und es wird auch geprüft, dass aus der Serverkonfiguration die Sicherheitsheader und die Maskierung der IP-Adresse in den Logs nicht verschwunden sind. Alle verwendeten GitHub-Aktionen sind auf die Commit-Prüfsumme festgelegt, und der Workflow startet mit `permissions: {}`.

Was zu lösen war

ungeprüft — wir haben die Quellen nicht, also kann ich das Arbeitsproblem nicht beschreiben, ohne es zu erfinden.

Was wir gebaut haben

React-Anwendung, mit Vite kompiliert, statisch von nginx ausgeliefert, mit russischer Version unter `/ru/`. 181 Adressen in der Produktions-Sitemap. Von außen kann nur das behauptet werden: Die Quellen sind nicht auf diesem Rechner, also kann ich weder die Bibliotheken noch die Struktur oder die Integrationen nennen.

Was zu lösen war

Ein zahnärztliches Kreiszentrum brauchte eine öffentliche Serviceliste mit Preisen, klare Kennzeichnung der von der obligatorischen Versicherung abgedeckten Leistungen, Team, Notdienstplan und Transparenzseiten — durch Personal editierbar, nicht durch einen Programmierer. Als wir das Projekt übernahmen, hatte das Administrationspanel ein schweres Problem: Das Admin-Passwort wurde im Browser verglichen und gelangte in das öffentliche JavaScript-Paket, und Schreibanfragen an die API konnten von jedem im Internet ausgeführt werden.

Was wir gebaut haben

React 18 + TypeScript-Anwendung auf Vite 6, mit `react-router-dom`-Routing — 22 Bildschirme, von Leistungen und Preisen bis zu Notfällen, Kieferorthopädie, Implantaten, Kinderzahnheilkunde, Transparenz und Feedback. Im Hintergrund ein Express-4-API unter PM2; nginx liefert die gebauten Dateien aus und leitet nur `/api` weiter. Die öffentlichen Daten (Leistungen, Team) liegen in JSON-Dateien, die sowohl vom API als auch direkt vom Frontend gelesen werden. Der Teil, den wir hinzugefügt haben, ist die Absicherung: Das Passwort verlässt den Server nicht mehr — `POST `login` prüft es dort und gibt ein mit HMAC-SHA256 signiertes Token mit einer Gültigkeit von 12 Stunden zurück, mit einer Grenze von 8 Versuchen pro 15 Minuten pro IP-Adresse und Vergleichen in konstanter Zeit; Schreibvorgänge auf `services` und `team` erfordern jetzt das Token; das Signiergeheimnis wird selbst in einer Datei mit Rechten 0600 erzeugt und außerhalb des Repos aufbewahrt; die API hört nur auf 127.0.0.1, also ist nginx der einzige öffentliche Weg; CORS ist auf die eigenen Domains beschränkt, und der JSON-Body ist auf 1 MB begrenzt. Darüber hinaus haben wir CI eingerichtet, das kompiliert, die Typen prüft und das Paket ablehnt, wenn es ein Secret darin findet, plus Dependabot mit wöchentlichem Rhythmus für npm.

Was zu lösen war

Ein Kreditunternehmen braucht mehr als eine Website: Der Antrag muss online eingehen, durch einen Entscheidungsfluss gehen, einen PDF-Vertrag erzeugen, einen Zahlungsplan generieren und eine Spur im Audit hinterlassen — und all das muss die Fragen eines Kunden aushalten, der seine personenbezogenen Daten zurückfordert. Der öffentliche Teil (Rechner, Artikel, Seiten nach Kreditart) muss zugleich Menschen aus der Suche anziehen.

Was wir gebaut haben

Zwei Hälften im selben Repository. Der öffentliche Teil ist eine statisch kompilierte Vite- + React-Router-Anwendung — 50 Bildschirme, darunter vier Rechner (Kredit, Eignung, Refinanzierung, Zahlungsplan), separate Seiten nach Kreditart, Blog, vorvertragliche Informationsseiten und Compliance-Seiten. Die rumänischen Routen bleiben ohne Präfix, und die russischen laufen über `/ru/…`, mit kanonischen und alternativen Etiketten, die aus der Sprache der aktiven Route erzeugt werden. Der Business-Teil ist ein modularer Express-Backend in TypeScript mit Prisma über PostgreSQL: 16 Module — Authentifizierung, Rollenrechte, Antragsfluss, Dokumente, Zahlungen, Benachrichtigungen, geplante Aufgaben, Blog, SEO, GDPR, Kunden, Leads, Kontakt, Rechner, Google Ads, Gesundheit — und 18 Tabellen im Prisma-Schema, darunter `Contract`, `Payment`, `AuditLog`, `GdprRequest`, `UploadedDocument`, `DailyKpiSnapshot` und `CronJobRun`. Es läuft unter PM2, mit separaten Skripten für Produktionsmigrationen, Vorabprüfungen vor dem Release, Generierung von Geheimnissen, Sicherung und Wiederherstellung der Datenbank.

Was zu lösen war

Eine Kfz-Werkstatt wird in sehr spezifischen Kombinationen gesucht — Marke plus Arbeit plus Stadtteil („Reparatur Automatikgetriebe BMW Botanica“). Eine einzige Seite „Dienstleistungen“ kann darauf nichts antworten. Das technische Problem ist, dass die Website eine einseitige React-Anwendung ist, also sieht die Suchmaschine nur ein leeres `<div>`, wenn nicht etwas Bestimmtes getan wird.

Was wir gebaut haben

React 19 + TypeScript-Anwendung auf Vite 6, mit React Router, aber beim Build vorgerendert: Jede Route kommt aus dem Build als eigene HTML-Datei heraus, also erhält die Suchmaschine Inhalt und keine leere Seite. Die Adressstruktur wurde schrittweise und im Verlauf überprüfbar erweitert — von 206 indexierbaren Seiten auf 316 durch das Hinzufügen von Kombinationen Marke × Kategorie der Arbeit, von Artikeln und von Seiten nach Sektor in Chișinău. Die Routen haben Sprachversionen, eine separate Bild-Sitemap, Open-Graph-Bilder und ein in Teile aufgeteiltes JavaScript-Paket für schnelleres Laden. Der letzte Commit hat ein Detail korrigiert, das die Indexierung still beschädigt: Die kanonische Adresse, `hreflang` und die Adressen in der Sitemap geben jetzt alle dieselbe Form mit abschließendem Schrägstrich aus.