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
Frontend: React Native mit TypeScript
State Management: Zustand + React Query
Backend: Supabase (PostgreSQL, Auth, Storage)
Hosting: Deutsche Rechenzentren (Hetzner)
Analytics: Selbst-gehostet (Plausible)
Monitoring: Sentry für Fehler-Tracking
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.
Für gesundheitsbezogene Features wie HealthKit- und Google Fit-Integration sind native Module nötig. Diese machen etwa 5% der Codebase aus.
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
TLS 1.3 für alle Datenübertragungen
AES-256 Verschlüsselung für ruhende Daten
Separate Verschlüsselungskeys pro Nutzer
Datenminimierung
Wir speichern nur, was wir wirklich brauchen. Keine IP-Adressen, keine Geräte-IDs, keine Tracking-Daten. Die User-ID ist ein zufälliger Hash ohne Bezug zu persönlichen Daten.
Deutsche Server
Alle Daten werden in deutschen Rechenzentren gespeichert. Das ist nicht nur DSGVO-konform, sondern gibt unseren Nutzern die Sicherheit, dass ihre Gesundheitsdaten nicht außerhalb der EU landen.
Unsere Server stehen in Nürnberg und Falkenstein – zertifiziert nach ISO 27001 für Informationssicherheit.
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 ohne Tracking
Wir brauchen Einblicke in App-Nutzung und Fehler – aber nicht auf Kosten der Privatsphäre. Unsere Lösung:
Plausible Analytics: Cookie-freie, DSGVO-konforme Nutzungsstatistiken
Sentry: Fehler-Tracking mit automatischer PII-Filterung
Custom Metrics: Aggregierte, anonymisierte Performance-Daten
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.