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.

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.

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.