Appearance
Avelia — Product Specification
Date: 2026-02-23 Tagline: Your journey to family, together.
What Avelia Is
Avelia is a mobile companion app (iOS + Android) for couples navigating the journey from "do we want a child?" through primary school. It is stage-aware, privacy-first, and built for two linked partners who each maintain their own account while selectively sharing data with each other.
The app combines daily tracking with journaling and curated guidance — so a symptom log feels like a diary entry, a milestone becomes a memory, and every week's guidance is relevant to exactly where the user is right now.
Core Principles
- Private by default — Data lives on-device first. Cloud sync is optional and end-to-end encrypted. No ads, no analytics, no third-party data sharing.
- Together, but personal — Each partner has their own account and their own view. Every log entry is explicitly marked private or shared; nothing crosses that line without intent.
- Stage-aware, not stage-gated — The app adapts to the user's current life chapter. No features are locked; the interface simply surfaces what's most relevant right now.
- Honest and warm — The app acknowledges the emotional weight of this journey alongside the clinical data. It doesn't reduce fertility, pregnancy, or early parenthood to charts.
User Model
Accounts
- Each person creates their own individual account with their own credentials.
- Accounts are linked via a one-time invite code. Either partner generates the code; the other enters it to connect.
- A user can use Avelia solo (without a linked partner) with full access to all features.
Privacy model
- Every log entry, journal entry, and data point has an explicit private | shared toggle.
- The default is private.
- When an entry is set to shared, it becomes visible to the linked partner in their view.
- The partner cannot see private entries — not even their existence.
- Sharing status can be changed at any time.
The 7 Stages
Stage is set during onboarding and can be updated at any time. The app adapts the home screen content, log types, and guidance based on the active stage.
| # | Stage | What the app focuses on |
|---|---|---|
| 1 | Considering | Values alignment conversations, financial readiness, preconception health, relationship check-ins |
| 2 | Trying naturally | Cycle tracking, ovulation prediction, basal body temperature (BBT), fertile window, mood and symptom logging |
| 3 | IVF / Assisted | Medication schedules and reminders, retrieval and transfer tracking, clinic appointments, embryo count tracker, emotional check-ins |
| 4 | Pregnant | Week-by-week fetal development, symptom logging, appointment tracker, birth plan builder |
| 5 | Birth & beyond | Birth story recording, contraction timer, hospital bag checklist, immediate postpartum support |
| 6 | First year | Feeding and sleep logs, growth tracking, vaccine schedule, developmental milestones |
| 7 | Growing up | Milestone tracking, activity logging, school preparation, family memory archive |
App Sections
Home
The home screen is a personal daily dashboard, adapted to the active stage.
Contents:
- Greeting and current stage indicator
- Today's snapshot — the most recent log entry with a quick-action prompt to add more
- This week — 2–3 pieces of curated guidance relevant to the current stage or week
- Partner's latest — the partner's most recent shared entry, if a partner is linked and has shared something
A persistent quick-log button is always accessible from this screen.
Log
A quick-entry screen for capturing what's happening right now. The fields and options adapt by stage:
- Considering: mood, conversation topics, decisions reached
- Trying naturally: cycle day, BBT, cervical mucus, ovulation test result, mood, symptoms
- IVF / Assisted: medication taken, dose, time; physical symptoms; mood; clinic visit notes
- Pregnant: symptoms, kicks/movement, weight, blood pressure, mood, notes
- First year: feeding (breast/bottle, duration/volume, time), sleep (start/end, type), nappy, mood
- Growing up: milestone achieved, activity, note
Each entry has a private/shared toggle set before saving.
Journal
A chronological timeline of all entries — logs, notes, and milestones.
- Displays a combined feed of the user's own entries and their partner's shared entries
- Visual distinction between own entries and partner entries
- Visual distinction between private and shared entries (only own private entries are visible to self)
- Entries can be filtered by: All / Shared / Private
- Tapping an entry opens it in full, with the option to edit sharing status
Guide
Curated content matched to the user's current stage and, where applicable, current week.
- A featured piece of content at the top (most relevant for right now)
- A scrollable list of articles, explainers, and checklists beneath it
- Content is tagged by topic (e.g. Development, Wellness, Partners, Nutrition)
- Sourced and reviewed; no user-generated content in this section
Us
The shared partner view — a space that belongs to both.
- Shows both partners' avatars and connection status
- Headline stats: days together in the app, number of shared entries, current stage milestone (e.g. weeks pregnant)
- A feed of recent shared moments from both partners
- Entry point for partner account management (linking, unlinking, invite)
IVF / Assisted Reproduction — Full Tracking Mode
When the IVF / Assisted stage is active, a dedicated sub-experience is available within the Log and Home sections.
Protocol timeline A visual step-by-step overview of the IVF cycle: Stimulation → Trigger → Retrieval → Fertilisation → Blast check → Transfer → TWW (two-week wait). The current step is highlighted; completed steps are marked.
Daily medication log
- Per-medication entries: drug name, dose, route (injection, oral, etc.), time taken
- Reminder support per medication
- Logged entries marked as done; missed entries flagged
Appointment tracker
- Clinic name, date, appointment type (baseline scan, monitoring scan, egg retrieval, embryo transfer, pregnancy test), notes
Embryo count tracker
- A running count through the cycle: eggs retrieved → fertilised → developed to blast → transferred → frozen
- Displayed as a simple progression; no clinical interpretation
Emotional check-in
- Daily mood and energy rating alongside clinical entries
- Private by default
- Appears as part of the daily log, not separated into a clinical module
Onboarding Flow
Three steps:
- Welcome — Introduction to Avelia, "Get started" CTA, sign-in link for existing users
- Partner setup — Choose between "Together" (link a partner) or "Solo" (no partner account). If Together is chosen, an invite is sent after setup; the partner creates their own account separately.
- Stage selection — Choose current stage from the 7 options. This can be changed at any time from settings.
Target: a couple completes onboarding and links accounts in under 3 minutes.
Privacy & Data Architecture
| Area | Behaviour |
|---|---|
| Storage | All data stored on-device (CoreData on iOS, Room on Android) |
| Cloud sync | Optional. End-to-end encrypted using a key generated and held by the user. Avelia cannot read synced data. |
| Partner sharing | Per-entry toggle. Default: private. Must be explicitly set to shared. |
| Analytics | None. No usage data is collected or transmitted. |
| Third-party SDKs | None. No ads, crash reporters, or analytics SDKs. |
| App lock | Biometric authentication (Face ID / fingerprint) on app open |
| Data export | Full JSON export of all personal data, available at any time |
| Account deletion | Permanent deletion of all data, available at any time |
Zero-Knowledge Architecture
Avelia is zero-knowledge: the server stores only encrypted blobs and can never read user data.
- Key generation — on account creation, the device generates a Master Encryption Key (MEK). The MEK never leaves the device and is never transmitted to Avelia servers.
- On-device encryption — all data (journal entries, cycle logs, symptoms) is encrypted with AES-256-GCM using the MEK before leaving the device.
- Server storage — Avelia servers store only ciphertext. Even employees and developers cannot read user entries.
- Court orders — if compelled to hand over data, Avelia can only provide ciphertext. Without the user's MEK, it is mathematically useless.
Data Security — Three Layers
| Layer | Protection |
|---|---|
| On device | Encryption keys stored in secure hardware (iOS Keychain / Android Keystore). Data encrypted at rest. Biometric or passcode required to access. |
| In transit | TLS 1.3 for transport security. Data is additionally E2E encrypted before reaching the network — double encryption. |
| On servers | Ciphertext only. Servers run in German data centres under EU jurisdiction. No plaintext data exists on the server at any time. |
Device hardening (defence against compromised phones):
- Secure enclave storage — MEK stored in tamper-resistant hardware, separate from main processor
- Memory protection — decrypted data cleared from memory when no longer needed; never written to disk/swap
- Jailbreak & root detection — warns user, activates additional protections on compromised devices
- Automatic session timeout — app locks after inactivity, purges decrypted data from memory
Safe Mode (updated 2026-04)
Safe Mode protects users in dangerous situations — abusive partners, repressive regimes, or family members who must not know. It is a core feature, not an afterthought.
On-device Safe Mode:
- A discreet gesture (alternate PIN or fingerprint) opens the app in Safe Mode
- The app shows plausible, automatically generated substitute data (regular cycles, neutral journal entries)
- Indistinguishable from normal use — same interface, no visible indicator
- Real data remains encrypted and inaccessible; only the real authentication restores it
Shared/sync Safe Mode (forced account linking):
- When Safe Mode is active, the linked partner sees the safe profile synced in real time — looks like a normal account
- No visible trace of a second profile — no settings toggle, no extra storage usage, no second account
- The user chooses per contact who sees real data and who sees only the safe profile; real sync and safe sync are cryptographically separated — one cannot reveal the other
Design principles:
- Deleting the app raises suspicion; Safe Mode lets users keep the app visible and unremarkable
- Apps with partner sharing normally give no way to participate without exposing everything; Safe Mode solves this
- The safe profile is maintained automatically with believable data patterns
Payment & Identity Architecture
Avelia supports three user paths with progressive privacy/convenience trade-offs. All three share the same internal architecture — they differ only at the signup and payment layers. See avelia-payment-identity.md for the complete spec.
The three user paths
| Path | Audience | Signup & payment | Identity visible to |
|---|---|---|---|
| Standard | Default (~85-90% of users) | In-app email + password signup; Apple IAP or Google Play Billing using appAccountToken / obfuscatedAccountId | Apple/Google — not Avelia directly |
| Anonymous (paid code) | Privacy-conscious users (~8-12%) | In-app redemption of a pre-minted code obtained from a clinic, midwife, reseller, or as a gift | Nobody — Avelia has no name, email, or card for these users |
| Avelia Fund | At-risk users, financially constrained (~2-5%) | Same redemption flow; the code was issued free to a partner NGO by Avelia | Nobody |
Database separation
Four databases with strict access boundaries. No SQL join across them is physically possible:
auth_db— accounts, email hashes (for Standard), account numbers (for Anonymous)entitlement_db— which account (by hash of UUID) has which tier, keyed so reverse lookup is impossiblepayment_db— Apple/Google subscription metadata, keyed by store subscription ID, NOT by Avelia account UUIDdata_db— encrypted user content, keyed by account UUIDcode_db— minted redemption codes (hashed), partner info, mint batches
Under court order, we can produce:
- Encrypted content blobs (unreadable without the user's Master Encryption Key)
- Payment records (without direct account linkage)
- Code metadata (not traceable to the redeeming user)
We cannot produce a cross-referenced profile of a specific user because the data does not exist in a queryable form in our infrastructure.
Apple / Google IAP — the appAccountToken pattern
Standard users pay via Apple IAP or Google Play Billing. The app passes appAccountToken = sha256(account_uuid) (iOS, StoreKit 2) or obfuscatedAccountId = sha256(account_uuid) (Android, Play Billing v4+). The receipt contains this opaque token. Avelia's backend verifies the receipt via Apple/Google APIs, extracts the token, and writes an entitlement.
Result: Apple/Google know the user's identity (Apple ID, Google account). Avelia does not. Avelia has only the opaque token and the account UUID it maps to. This is actually stronger privacy than direct Stripe checkout, which would attach an email to Avelia's records.
Code redemption
Anonymous and Fund users redeem in-app:
- Tap "I have a code"
- Enter
AVELIA-XXXX-XXXX-XXXXor scan QR - Backend validates, generates account UUID, writes entitlement
- User sets passphrase, generates Recovery Kit
- Subscription active
Codes are minted server-side, distributed externally (clinic, midwife, NGO, gift giver). Avelia never sees the distribution chain between mint and redemption.
Codes expire 3 years after mint (German statutory minimum for gift vouchers, BGB §195). Can be revoked and replaced if a batch leaks.
Avelia Fund
A program providing free Avelia Premium licenses to users who cannot safely pay for the app. Distributed via partner NGOs (Hilfetelefon, Pro Familia, bff, Frauenhauskoordinierung at launch). Funded by Avelia Health GbR's internal budget (5-10% of net revenue reserved). Not dependent on external grants in Phase 1.
Launch partners receive monthly code quotas. Distribute at their discretion. Avelia has no visibility into who receives codes beyond aggregate counts.
Annual transparency report published at /avelia-fund/transparency-report-YYYY — aggregate numbers only, no per-user data.
See avelia-payment-identity.md for the full operational model.
Hard architectural rules
These are non-negotiable once implementation begins:
- No primary key is email. Every internal ID is a UUID.
- Two separate database services (payment + data) with independent credentials and backup rotation. Cross-join must be physically impossible.
- Neutral billing descriptor for any directly-billed subscription (web gift codes). Apple/Google-controlled descriptors use a neutral App Store name.
- No A ↔ B migration path between Standard and Anonymous. Switching modes means "export, delete, re-create, import". Keeps the code simple and prevents identity leakage.
- Code plaintext is never stored. Only hashes. Redemption-time validation uses constant-time comparison.
- Entitlement checks use
hash(account_uuid), never the UUID directly.
Content Architecture
Avelia's content strategy spans the website and the in-app experience, with shared source-of-truth files to keep them aligned.
Content types
- Stage pillar content — For each of the 7 life stages, a long-form authoritative piece covering: what happens, common challenges, key decisions, when to seek medical attention, how Avelia helps. Used on the website (
/stages/[stage]) and as in-app stage introductions. - Glossary — 25 canonical definitions across privacy (8), fertility (6), IVF (5), and Avelia-specific terms (5). Each term ≤60 words, dictionary-style first sentence plus an Avelia implementation note. Used on the website (
/glossary) and as in-app tooltips/footnotes. - Privacy explainers — Three dedicated long-form pages (zero-knowledge, data security, Safe Mode). Each has hero narrative, supporting animated illustrations, technical summary block with extractable facts, and FAQ section. Used on the website and for in-app onboarding education.
- Homepage FAQ — 7 questions answering the most common user concerns. Rendered as visible HTML accordions AND as
FAQPageJSON-LD for search/LLM extraction. - Guides (CMS-driven) — Medical, evidence-based, reviewed by fertility/paediatric specialists. Each guide is tagged with stage, reading time, and review date.
- Blog articles (CMS-driven) — Narrative, opinion, behind-the-scenes, research commentary.
- Checklists (CMS-driven) — Actionable item lists, optionally interactive. Tagged with stage.
- Legal documents (CMS-driven, jurisdiction-aware) — Privacy policy, terms, impressum, cookie policy. Served based on detected jurisdiction.
Canonical reference files
Two text files published on the website for LLM crawlers and journalists:
/llms.txt— ~80-line index. Key technical facts, pricing, "what Avelia is not" disambiguation block, link list to major pages./llms-full.txt— ~2,500-word canonical long-form reference. 9 sections: product overview, 7 stages, privacy architecture (with specific algorithm names and jurisdictions), pricing, competitive positioning, FAQ, team, disambiguation, contact.
Both must be updated in the same commit as any substantive product change.
Content authoring discipline
See avelia-content-library.md for the full authoring rules. Key principles:
- Extractable facts: specific numbers, dates, algorithms, jurisdictions. Avoid vague marketing language.
- Named entity first: sentences start with "Avelia does X" not "We do X".
- Structural consistency: EN and DE translations must have matching keys and shape.
- Medical review: every clinical claim on guides requires sign-off from a credentialed reviewer.
- Evergreen over trendy: aim for content that will still be correct in 2 years.
Content → schema mapping
Every page type emits appropriate structured data (JSON-LD) for SEO and GEO:
| Page type | Schemas |
|---|---|
| Homepage | Organization, WebSite, SoftwareApplication (3 Offers), FAQPage |
| Privacy pages | WebPage, FAQPage |
| Stage pillar pages | WebPage, FAQPage, BreadcrumbList |
| Glossary | DefinedTermSet, BreadcrumbList |
| Blog articles | Article (with dateModified, timeRequired, wordCount), BreadcrumbList |
| Guides | MedicalWebPage (with reviewedBy), BreadcrumbList |
| Checklists | HowTo, BreadcrumbList |
See avelia-content-library.md §7 for details.
Success Criteria
- A couple can complete onboarding and link accounts in under 3 minutes
- The home screen communicates the user's current stage and most relevant actions at a glance
- No entry requires more than 3 taps to log
- Users feel the app respects the emotional weight of every stage
- Privacy controls are visible and understandable without reading documentation
Critical Risks & Mitigations
The "Lost Password" Problem
Risk: Because Avelia is Zero-Knowledge (we store only the salt, not the password or the Master Encryption Key), we cannot reset a user's password. If a user loses their password/credentials and has not set up recovery, their data is mathematically unrecoverable. This poses a high risk of churn and user distress, especially after months of logging.
Recovery Solutions
We will implement a tiered recovery strategy to mitigate this risk without compromising the privacy model.
Partner Recovery (Social Recovery)
- Concept: If two users are linked, the partner's device effectively holds a copy of the shared data keys. We can extend this to allow the partner to "vouch" for the user and securely re-share the keys.
- UX: "I lost my phone/password" -> Partner receives a request -> Partner approves -> Keys are re-synced to the user's new session.
- Pros: Seamless, reinforces the "Together" value prop.
- Cons: Requires a linked partner; doesn't help solo users.
The "Recovery Kit" (Sovereign Recovery)
- Concept: During onboarding, the user is prompted to save/print a "Recovery Kit" (PDF/Image) containing a QR code. This code encodes the Master Encryption Key (or a high-entropy recovery key).
- UX: "Scan your Recovery Kit to restore access."
- Pros: Works for solo users; 100% offline and secure.
- Cons: Users often skip this step or lose the file.
Platform Backup (Pragmatic Recovery)
- Concept: Optionally store an encrypted copy of the MEK in the OS-native secure cloud (iCloud Keychain for iOS, Google Password Manager/Block Store for Android).
- UX: "Restore from iCloud/Google" button on the login screen.
- Pros: Extremely high success rate; familiar to users (similar to WhatsApp/Signal backup).
- Cons: Relies on Big Tech infrastructure (though Avelia servers remain zero-knowledge).