Partner
Ride-Guard
Case Study12
Next.js-basierte Notfall-Plattform für Motorradfahrer und Abenteurer mit NFC-Chip und QR-Code-Integration

Partner
Ride-Guard
Branche
Gesundheitswesen
Kerntechnologien
Next.js · Supabase · Stripe
Auf einen Blick
Ride-Guard verkauft wetterfeste Sticker mit NFC-Chip und QR-Code für Helm und Verkleidung. Wer nach einem Unfall hilft, scannt den Sticker und sieht ohne Anmeldung die medizinischen Angaben und Notfallkontakte, die der Besitzer hinterlegt hat. DuoByte hat die Web-Plattform dahinter entwickelt, von der Aktivierung über das öffentliche Notfallprofil bis zum Shop mit Stripe und dem automatisierten Deployment.
Unsere Rolle: DuoByte hat die Plattform von der Datenbank bis zur Deployment-Pipeline entwickelt und erweitert sie seitdem, zuletzt um neue Produktvarianten und Versandoptionen im Shop.
Projektarbeit
Wie das Projekt entstanden ist: vom Kontext und den Anforderungen über die Umsetzung bis zum heutigen Stand.
Ausgangslage
Nach einem Unfall können Verletzte oft nicht selbst sagen, welche Medikamente sie nehmen, welche Allergien sie haben oder wen man verständigen soll. Ride-Guard löst das mit einem Sticker, der auf Helm oder Kunststoffverkleidung klebt und einen NFC-Chip und einen QR-Code trägt. Er richtet sich an Motorrad- und Radfahrer, Bergsteiger und alle, die draußen unterwegs sind.
Die Plattform hat zwei sehr unterschiedliche Nutzergruppen. Besitzer legen ihr Profil einmal an und halten es aktuell, in Ruhe und am eigenen Gerät. Ersthelfer und Rettungskräfte öffnen es dagegen in einer Ausnahmesituation, ohne Konto, ohne Anleitung und nicht unbedingt mit Deutschkenntnissen.
Herausforderung
Das Notfallprofil muss ohne Anmeldung erreichbar sein, sonst hilft es am Unfallort niemandem. Gleichzeitig enthält es Gesundheitsdaten, die nur der Besitzer ändern darf. Ein verkaufter, aber noch nicht aktivierter Sticker darf keine Daten zeigen und auch nicht von Dritten übernommen werden.
Dazu kommt der Verkauf. Sticker werden in Chargen gedruckt, bevor es einen Besitzer gibt, und über einen eigenen Shop mit Versand verkauft. Preise dürfen sich im Browser nicht manipulieren lassen, Test- und Live-Zahlungen müssen strikt getrennt bleiben.
Viele Besitzer nutzen mehr als einen Sticker, etwa auf zwei Helmen. Die Daten sollen trotzdem nur an einer Stelle gepflegt werden.
Lösung
Jeder Sticker bekommt beim Erzeugen der Druckcharge eine 16-stellige ID in Viererblöcken und eine PIN. Die ID verzichtet auf leicht verwechselbare Zeichen wie 0 und O oder 1, I und L, damit sie sich vom Aufdruck sicher abtippen lässt. Wird ein noch nicht aktivierter Sticker gescannt, öffnet sich die Aktivierungsseite, auf der der Käufer mit ID, PIN, E-Mail-Adresse und Passwort sein Konto anlegt.
Im geschützten Bereich pflegt der Besitzer sein Profil: Foto, Geburtsdatum, Größe, Gewicht, Blutgruppe, Medikamente, Allergien, Vorerkrankungen, Schwangerschaft, Organspendestatus, freie Hinweise und bis zu fünf Notfallkontakte. Weitere Sticker verknüpft er als Zusatz-Sticker mit seinem Konto, und wer einen davon scannt, landet auf dem Hauptprofil. Sein Konto kann er selbst löschen, dabei entfernt die Plattform Profildaten, Sticker-Zuordnungen und Fotos.
Das öffentliche Profil ist für die Lage am Unfallort gebaut: klar getrennte Abschnitte, Beschriftungen auf Deutsch und Englisch und Notfallkontakte als Telefonnummern, die sich direkt antippen und anrufen lassen. Verkauft werden die Sticker über den integrierten Shop.
Umsetzung
Die Anwendung basiert auf Next.js 15 mit dem App Router und TypeScript, gestaltet mit Tailwind CSS. Routengruppen trennen öffentliche Seiten, Anmeldung, geschützten Bereich und Shop. Formulare laufen über React Hook Form mit Zod-Schemas, und die API-Routen prüfen jede Anfrage noch einmal mit Zod, bevor sie sie weitergeben.
Die Daten liegen in Supabase auf PostgreSQL. Gelesen und geschrieben wird über Datenbankfunktionen mit ausdrücklich vergebenen Ausführungsrechten statt über direkten Tabellenzugriff. Die öffentliche Abfrage liefert nur aktivierte Sticker und nur die Felder des Notfallprofils, die Profilaktualisierung prüft Anzahl und Aufbau der Notfallkontakte, und beim Aktivieren wird der Datensatz gesperrt, damit kein Sticker doppelt vergeben wird. Fotos sind öffentlich lesbar, schreiben darf sie nur der Besitzer.
Was Administratorrechte braucht, etwa das Anlegen und Löschen von Konten, läuft in Supabase Edge Functions, sodass der Dienstschlüssel den Server nie verlässt. Auch die Checkout-Sitzung entsteht dort: Preise kommen aus einem serverseitigen Katalog mit Versionskennung, der Browser übermittelt nur Produkt-IDs und Mengen. Die Funktion akzeptiert ausschließlich Live-Schlüssel, die lokale Entwicklung ausschließlich Testschlüssel.
Ausgeliefert wird ein Docker-Image aus einem mehrstufigen Build. Docker Compose betreibt den Next.js-Container zusammen mit Caddy als Reverse Proxy, der HTTPS-Zertifikate automatisch bezieht und Zweitdomains umleitet. Jeder Push auf den Hauptzweig startet über GitHub Actions ein Deployment per SSH mit schreibgeschütztem Deploy-Key, und die Ersteinrichtung des Servers liegt als Skript im Repository.
Ergebnis
Ride-Guard verkauft seine Sticker im eigenen Shop, Käufer aktivieren sie selbst und pflegen ein einziges Profil für alle ihre Sticker. Wer am Unfallort scannt, sieht die hinterlegten Angaben ohne App und ohne Konto, dank englischer Beschriftung auch ohne Deutschkenntnisse.
Die Plattform ist in Betrieb und wird weiter ausgebaut. Zuletzt kamen neue Farb- und Paketvarianten, der Versand per Einschreiben und vollständige Bestelldetails in den Stripe-Daten hinzu. Änderungen, auch Textanpassungen durch den Betreiber, gehen über dieselbe Pipeline live.
Produkt & Kontext
Ausgewählte Ansichten zeigen, wie das System im fachlichen Kontext gedacht und umgesetzt wurde.


Systemarchitektur
Technologien wurden passend zur Aufgabe, zum Betriebsmodell und zur langfristigen Wartbarkeit kombiniert.
Verwandte Leistungen
Geschützte Portale für Kunden, Händler und Mitglieder: Bestellungen, Buchungen und Dokumente im Self-Service, mit klaren Rollen und Freigaben.
Mehr erfahrenBackend-Erfahrung aus der ePA, eine Terminplattform für ein Praxisnetz und Architekturen, die Art. 9 DSGVO und § 393 SGB V von Anfang an berücksichtigen.
Mehr erfahrenWeiter entdecken
Nächste Case Study

Ihr Projekt
Erzählen Sie uns, was Ihr System leisten muss. Wir bringen Struktur in Anforderungen, Architektur und Umsetzung.