Aktualisierung vom 15. September 2026: Der ursprüngliche Beitrag von 2025 enthielt konkrete Hosting- und Analytics-Beispiele, die nicht mehr alle aktuellen Elara-Datenflüsse abbildeten. Diese Aussagen wurden korrigiert. Für Auftragsverarbeiter, Verarbeitungsorte, Speicherdauer und Transfergarantien sind die aktuellen Datenschutzerklärungen maßgeblich.
Als Solo-Entwickler mit begrenzten Ressourcen musste ich bei der technischen Architektur von Elara sehr bewusste Entscheidungen treffen. Dieser Artikel gibt Einblicke in unseren Tech-Stack und die Überlegungen dahinter.
Der Tech-Stack im Überblick
App-Frontend: React Native mit TypeScript
Website: Next.js mit TypeScript
Backend-/Datenbankdienste: Supabase, soweit im jeweiligen Produktablauf eingesetzt
Website-Hosting: Vercel
Website-Analytics: PostHog nur nach Statistik-Einwilligung
Website-Fehleranalyse: Sentry mit minimierter Fehlertelemetrie
Warum React Native?
Die Entscheidung für React Native war pragmatisch: Als Einzelperson kann ich nicht zwei native Apps parallel entwickeln und warten. React Native erlaubt mir, 95% des Codes zwischen iOS und Android zu teilen.
Gesundheitsdaten-Anbindungen benötigen plattformspezifische oder native Schnittstellen. Elara unterstützt aktuell Apple Health und Android Health Connect; hinzu kommen aktive Integrationen für Garmin, Fitbit und Oura.
TypeScript war von Anfang an gesetzt. Bei Gesundheitsdaten ist Typsicherheit nicht optional – sie verhindert ganze Kategorien von Bugs, die bei dynamischer Typisierung durchrutschen könnten.
Backend: Supabase
Supabase ist ein Open-Source Firebase-Alternative mit PostgreSQL als Datenbank. Die Vorteile für Elara:
PostgreSQL: Bewährt, zuverlässig, SQL-basiert
Row Level Security: Datenschutz auf Datenbankebene
Realtime: Live-Updates ohne zusätzliche Infrastruktur
Auth: Sichere Authentifizierung out-of-the-box
Self-hosting möglich: Volle Kontrolle über Daten
Besonders wichtig: Supabase kann selbst gehostet werden. Das gibt uns die Flexibilität, bei Bedarf auf eigene Server zu migrieren – ohne Code-Änderungen.
Datenschutz by Design
Bei Gesundheitsdaten ist Datenschutz keine nachträgliche Überlegung. Hier ist, wie wir ihn von Anfang an eingebaut haben:
Verschlüsselung
Verschlüsselte Übertragung per HTTPS/TLS bei Netzwerkkommunikation
Verschlüsselung ruhender Daten entsprechend der tatsächlich eingesetzten Dienste und Konfigurationen
Zugriffsbeschränkung und Datenminimierung statt pauschaler Aussagen über ein einheitliches Schlüsselmodell
Datenminimierung
Wir verfolgen das Prinzip der Datenminimierung: Es sollen nur Daten verarbeitet werden, die für den jeweiligen Zweck erforderlich sind. Technisch notwendige Verbindungsdaten wie IP-Adressen können bei Hosting, Sicherheits- oder Rate-Limit-Prozessen dennoch anfallen. Optionale Website-Analyse erfolgt nur nach Einwilligung. Maßgeblich für die aktuellen Datenflüsse ist die jeweilige Datenschutzerklärung.
Verarbeitungsorte und Dienstleister
Elara nutzt für unterschiedliche Funktionen unterschiedliche Dienste. Verarbeitungsorte, Empfänger und gegebenenfalls Drittlandübermittlungen hängen von der konkreten Funktion und Konfiguration ab. Deshalb machen wir keine pauschale Aussage, dass sämtliche Systeme in deutschen Rechenzentren betrieben werden. Die aktuellen Angaben stehen in der Website- beziehungsweise App-Datenschutzerklärung.
Konkrete Anbieter, Verarbeitungsorte und Schutzmechanismen können sich mit der technischen Architektur ändern. Deshalb verweisen wir für den aktuellen Stand auf die jeweiligen Datenschutzerklärungen statt auf pauschale Standortversprechen.
Performance-Optimierungen
Menschen mit Brain Fog haben wenig Geduld für langsame Apps. Deshalb haben wir von Anfang an auf Performance geachtet:
Lazy Loading: Screens werden erst geladen, wenn sie gebraucht werden
Optimistische Updates: UI reagiert sofort, Sync läuft im Hintergrund
Offline-First: Die App funktioniert auch ohne Internet
Bildkomprimierung: Alle Assets sind WebP-optimiert
Code Splitting: Kleinere Bundle-Größe, schnellerer Start
Monitoring mit Datenminimierung
Website und App haben unterschiedliche Telemetrie- und Datenschutzkontexte. Für die Website gilt derzeit:
Website-Analytics: PostHog nur nach aktiver Statistik-Einwilligung; Fragebogen- und OAuth-Pfade sind ausgeschlossen
Website-Fehleranalyse: Sentry ohne Performance-Tracing oder Session Replay und mit Datenminimierung vor der Übermittlung
App-Telemetrie und die Verarbeitung von Gesundheitsdaten in der App richten sich separat nach den App-Einstellungen und der App-Datenschutzerklärung
Lessons Learned
Ein paar Dinge, die ich anders machen würde, wenn ich nochmal von vorn anfangen würde:
Früher auf TypeScript strict mode wechseln
Von Anfang an E2E-Tests schreiben
Mehr Zeit für CI/CD-Pipeline investieren
Design System vor Feature-Entwicklung aufbauen
Insgesamt bin ich zufrieden mit den technischen Entscheidungen. Der Stack ist solide, wartbar, und skaliert mit. Mehr kann man als Solo-Entwickler nicht verlangen.