Update, September 15, 2026: The original 2025 article contained specific hosting and analytics examples that no longer represented every current Elara data flow. We have corrected those statements. The current Privacy Policies remain authoritative for processors, locations, retention, and transfer safeguards.
As a solo developer with limited resources, I had to make very deliberate choices about Elara's technical architecture. This article gives an overview of our stack and the reasoning behind it.
The Stack at a Glance
App frontend: React Native with TypeScript
Website: Next.js with TypeScript
Backend/database services: Supabase where used by the relevant product flow
Website hosting: Vercel
Website analytics: PostHog only after statistics consent
Website error monitoring: Sentry with minimized error telemetry
Why React Native?
The choice of React Native was pragmatic: as a single person, I cannot build and maintain two native apps in parallel. React Native allows me to share around 95% of the code between iOS and Android.
Health-data integrations require platform-specific or native interfaces. Elara currently supports Apple Health and Android Health Connect, complemented by active integrations for Garmin, Fitbit, and Oura.
TypeScript was non-negotiable from the start. With health data, type safety is not optional - it eliminates whole categories of bugs that can slip through in dynamically typed systems.
Backend: Supabase
Supabase is an open-source alternative to Firebase built on PostgreSQL. For Elara, it offered several concrete advantages:
PostgreSQL: proven, reliable, SQL-based
Row Level Security: privacy enforcement directly in the database
Realtime: live updates without extra infrastructure
Auth: secure authentication out of the box
Self-hosting possible: full control over data
That last point matters in particular: Supabase can be self-hosted. It gives us the flexibility to migrate to our own servers if needed - without rewriting the application.
Privacy by Design
With health data, privacy cannot be an afterthought. Here is how we built it in from the beginning:
Encryption
Encrypted transport via HTTPS/TLS for network communication
Encryption at rest according to the services and configurations actually used
Access controls and data minimization instead of blanket claims about one uniform encryption-key model
Data Minimization
We follow data-minimization principles: data should only be processed where needed for the relevant purpose. Technically necessary connection data such as IP addresses can nevertheless arise in hosting, security, or rate-limiting processes. Optional website analytics is used only after consent. The applicable Privacy Policy is the authoritative source for current data flows.
Processing Locations and Service Providers
Elara uses different service providers for different functions. Processing locations, recipients, and any international transfers depend on the specific service and configuration, so we do not make a blanket claim that every system is hosted in Germany. The current Website and App Privacy Policies are the authoritative sources for these details.
Trade-offs and Reality
Every architectural decision has trade-offs. React Native is not perfect. Self-hosting adds operational burden. Strong privacy constraints reduce some product analytics options. But these trade-offs are acceptable because they align with the product we want to build.
If privacy and reliability are core product promises, they have to shape the architecture - not be bolted on later.
Conclusion
Elara's architecture is intentionally conservative in the right places and pragmatic in others. The goal was never to build the most fashionable stack. The goal was to build something maintainable, secure, and trustworthy for people managing complex chronic conditions.
If there is interest, I can write a follow-up on how we handle questionnaire scoring, storage security, and cross-platform health integrations in more detail.