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
Frontend: React Native with TypeScript
State management: Zustand + React Query
Backend: Supabase (PostgreSQL, Auth, Storage)
Hosting: German data centers (Hetzner)
Analytics: self-hosted (Plausible)
Monitoring: Sentry for error tracking
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.
For health-related integrations such as HealthKit and Google Fit, native modules are still required. Those represent about 5% of the codebase.
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
TLS 1.3 for all data transfers
AES-256 encryption for data at rest
Separate encryption keys per user
Data Minimization
We store only what we truly need. No IP addresses, no device IDs, no unnecessary tracking data. The user ID is a random hash with no direct connection to personal information.
Why Germany?
Hosting in Germany was not just symbolic. It reduces legal complexity, strengthens user trust, and makes GDPR compliance operationally simpler. For our audience, server location is not a marketing detail - it is a trust signal.
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.