Legal & Compliance

GDPR Article 13 requires that, at the moment personal data is collected from the data subject, the controller provides identity and contact details of the controller, purposes and legal basis for processing, recipients/categories of recipients, intention to transfer to third countries, retention periods, and the user's rights (access, rectification, erasure, restriction, portability, objection, complaint to a supervisory authority). The app collects extensive personal data on signup (email, password, display_name, preferred_language) and then on use (biometrics, body_measurements, body photos, cycle_logs, coach conversations with mental-health-adjacent content, meal photos with potential face content) and gives the user no document explaining any of this. The localized sentence claims a 'Privacy Policy' exists, which makes the absence a representation issue on top of a compliance issue: the app affirmatively tells users a policy exists that does not exist.

Cannot launch in the EU. A DPA (data protection authority) complaint or audit would find this on day one; fines under GDPR Article 83 reach up to 4% of global annual turnover or EUR 20 million, whichever is higher. For a B2C app handling biometric/health-adjacent data, this is the single most common reason for a launch-block by counsel review. Additionally, the false claim 'By continuing you agree to our Terms and Privacy Policy' shown to every user on signup is itself a consumer-protection issue (misleading commercial practice under EU Directive 2005/29/EC), independent of the GDPR exposure. App-store reviewers (Apple, Google) reject apps without a privacy policy URL: if this is ever submitted as a PWA-wrapper or native shell, the listing will be blocked.

Your app currently has no privacy policy of any kind, but tells every new user 'By continuing you agree to our Terms and Privacy Policy' promising a document that does not exist. In the EU this single issue blocks launch: every regulator and every lawyer reviewing the product will stop here. You need a real privacy policy, linked from the signup screen, before going live.

1. Engage a privacy lawyer (or use a vetted template generator like iubenda, Termly, or Cookiebot's policy module) to draft a GDPR-compliant privacy policy that names: (a) the legal-entity controller and their EU representative if applicable; (b) every category of personal data collected (auth, profile, biometric/body, cycle, coach conversations, photos, push tokens, language/region); (c) the legal basis per category (consent for special-category biometric data per Art. 9, contract for service delivery per Art. 6(1)(b), legitimate interest for security logs); (d) all subprocessors (Supabase, Cloudflare, Lovable, OpenAI, Google) and the data they receive; (e) international-transfer mechanism (SCCs) for each non-EU subprocessor; (f) retention periods (e.g. body photos auto-purge at 90 days per `settings.tsx:577-582`); (g) the user rights and how to exercise them (email contact plus in-app delete/export endpoints once those exist, see LEG-003); (h) cookie/local-storage usage.
2. Create `src/routes/privacy.tsx` rendering the document (markdown-loaded, localized in all 6 supported languages).
3. Replace the dangling text in `auth.tsx:265-267` with React Link to /privacy and Link to /terms tags around the relevant clauses, in every locale's `auth.legal` translation.
4. Add a footer link on every page (or at minimum on /, /auth, /settings).
5. Surface the privacy-policy URL in app-store listings and on any marketing site.

M — 1–3 days

• https://gdpr-info.eu/art-13-gdpr/
• https://gdpr-info.eu/art-14-gdpr/
• https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en

EU consumer law (Directive 2011/83/EU on consumer rights, Directive 93/13/EEC on unfair terms in consumer contracts, and national implementations) requires that, before a consumer is bound by a contract via electronic means, the key terms must be displayed in a clear, comprehensible manner and the consumer must give explicit consent to them. Showing the user a sentence that names 'Terms' without exposing the actual terms means the user cannot meaningfully consent and any clause the controller later tries to rely on (liability limitation, dispute resolution forum, subscription auto-renewal, content licensing for user-generated photos, AI-output disclaimers) is at risk of being unenforceable. The app also processes user-generated content (meal photos, body photos, coach conversations) that is fed into a third-party AI gateway (Lovable, OpenAI, Google) without a Terms document specifying the user's license grant for that processing, the controller has no contractual basis for the transfer.

Cannot enforce any terms against users (no contract was formed). Any future dispute over abuse, payment, AI output liability, or content removal is fought without the protections a ToS would provide. Combined with LEG-001, this blocks EU launch and app-store submission. Specific exposure for this product: the coach has explicit safety-rail prompts around medical/mental-health risk (mental-health-risk.ts, medical-safety.ts, emergency-signals.ts per stack-profile section 6) without a ToS containing the standard 'this is not medical advice, not a substitute for professional care, in emergencies contact local emergency services' disclaimer, any harm a user attributes to coach output is litigated without that defense. (The product description in `__root.tsx:61` does include 'Not medical advice' in meta-description text, but a meta description is not legally operative.)

Your app has no Terms of Service document, just a sentence on signup saying users 'agree to our Terms.' Legally, no agreement is formed when you do not show the user what they are agreeing to. This is a launch blocker, and for a product that gives AI-driven longevity coaching it is also a significant liability gap if a user ever claims harm from the coach's output.

1. Draft a Terms of Service covering: (a) service description and limitations ('SO:NI is a wellness coach, not a medical/diagnostic service'); (b) eligibility (18+ recommended given the mental-health-adjacent coach surface; see LEG-008 children-data handoff); (c) account rules, prohibited uses, abuse policy; (d) AI-output disclaimer with explicit not-medical-advice language and emergency-services directive; (e) user content license grant covering the photos, meal data, coach messages being processed by AI subprocessors; (f) subscription/cancellation terms if/when monetisation lands; (g) liability cap, indemnity, dispute-resolution clause appropriate to the controller's home jurisdiction (likely HU/EU); (h) changes-to-terms procedure (e.g. 30-day notice via email plus in-app banner).
2. Create `src/routes/terms.tsx` rendering the document, localized in all 6 supported languages.
3. Convert the `auth.legal` sentence in all 6 locale files into a translation with two embedded link placeholders, and render via <Trans i18nKey='auth.legal' components={{ termsLink: <Link to='/terms' />, privacyLink: <Link to='/privacy' /> }} />.
4. For signup specifically, consider a separate checkbox 'I have read and agree to the Terms and Privacy Policy' that must be ticked before the signup button enables, strongest evidence of consent.
5. Add footer links on every page.

M — 1–3 days

• https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32011L0083
• https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:31993L0013

GDPR Articles 15-22 grant every EU data subject the following rights, which the controller must be able to honour within one month (Article 12(3)): right of access (15), rectification (16), erasure / right to be forgotten (17), restriction of processing (18), notification (19), data portability (20), objection (21), and the right not to be subject to automated decision-making (22). The app implements none of them as a self-service flow. Practically: (a) a user cannot delete their account at all from inside the app; (b) a user cannot download their data in a machine-readable form; (c) a user cannot withdraw consent for AI-coach memory or for the coach to read their cycle/safety data, all of which are processed under what should be revocable consent for Article 9 special-category processing. Without these endpoints, the controller cannot honour an Article 17 erasure request without a manual, human-touched workflow and given the 42 tables that reference user_id, manual deletion is error-prone and likely to leave orphaned data.

Cannot lawfully launch in the EU. Receiving even one user data-deletion request after launch forces the controller into a manual SQL-and-Storage-purge exercise across 42 tables and 7 Storage buckets per user, with no audit trail; missing any row is itself a GDPR violation. The right of access (Article 15) likewise: if a user emails 'please send me everything you hold on me,' the controller has 30 days to comply. With biometric plus cycle plus mental-health-adjacent coach-conversation data on file, that response would be a complex JSON export; a manual extract is not a sustainable answer at any user count. App-store submissions (Apple in particular, since iOS 14.5) explicitly require an in-app 'Delete Account' button: the app would be rejected on first review.

EU privacy law gives every user three rights you have to honour: delete my account, download my data, and stop using my data for a specific purpose. Your app currently supports none of them. The 'Full reset' button in Settings clears daily entries but keeps the account, the coach memory and the body history, so it is not the GDPR 'delete my account' flow. Apple also rejects apps without an in-app delete-account button. Both legally and for app-store approval, this needs to be built before launch.

1. Add an in-app 'Delete account' button in `src/routes/settings.tsx` (separate from 'Full reset', clearly labelled as irreversible). Implement a server function deleteUserAccount(userId) that: (a) deletes all rows referencing the user across the 42 tables in a single transaction (use supabase.auth.admin.deleteUser plus explicit cascades, or rely on ON DELETE CASCADE foreign keys if the migration history has them, verify against the data-integrity audit findings); (b) deletes all Storage objects under the user's folder in each of the 7 buckets; (c) finally deletes the auth.users row.
2. Add a 'Download my data' button that produces a JSON ZIP archive of all rows where user_id = auth.uid() plus signed URLs to their Storage objects, valid for 7 days. Implement as a server function that streams the assembled archive.
3. Add granular consent toggles in Settings for: AI coach memory retention; processing of cycle data; processing of body photos. Each toggle should both stop future processing AND offer a one-click 'delete past data for this category.'.
4. For Article 22 (no automated decision-making with significant effects): document in the privacy policy that AI coach output is advisory only, no automated decision with legal/significant effect is made, and the user can always switch to non-AI mode.
5. Log all subject-rights actions in a gdpr_actions audit table (timestamp, user_id, action, completed_at) for the controller's Article 30 records.
6. Establish a dpo@<domain> or privacy@<domain> email mailbox referenced from the privacy policy as the escalation path for rights requests the in-app flow does not cover.

L — 1–2 weeks

• https://gdpr-info.eu/art-15-gdpr/
• https://gdpr-info.eu/art-17-gdpr/
• https://gdpr-info.eu/art-20-gdpr/
• https://developer.apple.com/news/?id=mdkbobfo

GDPR Article 28

(1) requires the controller to use only processors providing 'sufficient guarantees' and to have a written contract (DPA) with each. Article 28(2)-

(4) requires the controller to authorise sub-processors and disclose changes. Article 30 requires a Record of Processing Activities that lists each processor, the categories of personal data processed, and the safeguards in place. For a single-developer or small-team product, these obligations are commonly met by: (a) signing the standard DPA each vendor offers (Supabase, Cloudflare, OpenAI, Google all publish DPAs; Lovable's status is unknown and should be verified); (b) publishing the subprocessor list inside the privacy policy. Neither has visible evidence. The OpenAI and Google paths are particularly material because the data flowing through is special-category (biometric photos, cycle data, mental-health-adjacent coach text) and the providers are US-based, requiring Standard Contractual Clauses for the international transfer (Article 46). The og:image hosted on a Cloudflare R2 public URL (`__root.tsx:68`) also indicates Cloudflare R2 is in use for at least static assets, this is another subprocessor to enumerate.

Two distinct exposures. First, contractual: without DPAs in place, every API call to OpenAI/Google/Lovable that ships personal data is an unlawful disclosure to a non-authorised third party, each user could in theory claim Article 82 compensation. Second, transfer-mechanism: without SCCs for the US-bound providers, the transfers are unlawful under Article 44 (post-Schrems II). Both are findable in any GDPR audit, both can be cured before launch by signing the vendors' standard DPAs and listing them in the privacy policy. The cost of the cure is low (sign 4-5 DPAs, none of which are negotiated for a product this size, vendors offer them as-is), but it must happen before launch.

Every time a user sends a message or a photo to the coach, that data passes through Lovable, OpenAI, and Google. EU law requires you to have a signed 'data processing agreement' with each of these companies and to list them in your privacy policy. None of that paperwork is visible in the project right now. The good news: every one of these vendors offers a standard agreement you can sign in a few minutes; the bad news: you cannot launch in the EU until that paperwork is on file.

1. Sign the Data Processing Agreement offered by each subprocessor: Supabase (https://supabase.com/legal/dpa), Cloudflare (https://www.cloudflare.com/cloudflare-customer-dpa/), OpenAI (https://openai.com/policies/data-processing-addendum), Google Cloud (https://cloud.google.com/terms/data-processing-addendum). For Lovable specifically, request a DPA from Lovable support, confirm whether they pass through to OpenAI/Google as sub-processors with their own DPA chain.
2. Confirm each vendor's EU SCCs are in place for international transfers (the modular SCCs published by the European Commission in 2021, all four major vendors include them by default in their DPA).
3. Create a Record of Processing Activities document (a simple spreadsheet is enough at this stage; vendors like iubenda offer templates) listing: data category, purpose, legal basis, retention, subprocessor, transfer mechanism.
4. Publish the subprocessor list inside the privacy policy (LEG-.
5. and commit to giving users 30 days' notice before adding a new subprocessor.
6. Configure the Supabase project's region to an EU region if it is not already (the project id `oyajjhkigkffvudjgybp` reveals nothing about region; verify in the Supabase dashboard).
7. For the Cloudflare Worker, confirm the deployment region restrictions if any.

M — 1–3 days

• https://gdpr-info.eu/art-28-gdpr/
• https://gdpr-info.eu/art-30-gdpr/
• https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en

Post-Schrems II (CJEU C-311/18, July 2020) and after the invalidation of Privacy Shield, transfers of EU personal data to the US require either (a) reliance on the EU-US Data Privacy Framework (the adequacy decision adopted in July 2023, valid for vendors that are DPF-certified), or (b) signed Standard Contractual Clauses plus a documented Transfer Impact Assessment, or (c) one of the narrow derogations in Article 49. The app sends biometric photos (special category, Article 9), coach conversations (potentially mental-health-adjacent), and cycle data to OpenAI and Google via the Lovable gateway, all US-headquartered companies. For each vendor the controller must determine: (i) is the vendor DPF-certified, and is the data category covered? (ii) if not DPF-only, are SCCs in place via the vendor DPA? (iii) has the controller performed a Transfer Impact Assessment? None of this is documented in the repository.

An EU data-protection authority that learns of US transfers of special-category data without a documented transfer mechanism can order suspension of the processing within days. For a coach product whose core feature IS the AI conversation, suspension of the AI subprocessor is an effective service shutdown. The fix is paperwork-only (verify DPF certification status of each vendor as of audit date, sign SCCs as a fallback, document the TIA) and can be completed in 1-2 weeks. The cost of not doing it is binary: a complaint to NAIH (Hungarian DPA), CNIL (French DPA), or any other EU DPA can result in an enforced processing-suspension order.

Sending European users' data to American companies (OpenAI, Google) requires a specific legal mechanism, either a current EU adequacy decision for that company, or signed contracts called Standard Contractual Clauses. You need to verify, for each vendor, which mechanism applies and document it. This is a paperwork task, not a code change, but it is mandatory before launching to EU users.

1. For each US-headquartered subprocessor (OpenAI, Google, Cloudflare, Lovable if US-based), check the EU-US Data Privacy Framework participants list (https://www.dataprivacyframework.gov/list) for current DPF certification and the specific data categories covered.
2. For any vendor not DPF-certified for the relevant data category, ensure the signed DPA includes the European Commission's 2021 modular Standard Contractual Clauses (Module 2: controller-to-processor). All four vendors include them as standard.
3. Perform a one-page Transfer Impact Assessment per vendor documenting: data categories, recipient country, surveillance-law exposure, supplementary measures (encryption in transit, encryption at rest, minimisation of data sent). For an AI gateway call, document specifically that the data sent is the prompt plus image (not the full DB), processed for inference only, and not retained by the vendor per their DPA.
4. Publish the transfer mechanism in the privacy policy (LEG-001), for each subprocessor: 'Transfers occur under the EU-US DPF / Standard Contractual Clauses (2021).'.
5. Verify the Supabase project region: if it is not already EU (e.g. eu-central-1, eu-west-1), migrate or document the controller's risk acceptance.

M — 1–3 days

• https://gdpr-info.eu/art-44-gdpr/
• https://gdpr-info.eu/art-46-gdpr/
• https://www.dataprivacyframework.gov/list
• https://edpb.europa.eu/our-work-tools/our-documents/recommendations/recommendations-012020-measures-supplement-transfer_en

GDPR Article 35 requires a Data Protection Impact Assessment when processing is 'likely to result in a high risk to the rights and freedoms of natural persons.' The EDPB and most national DPAs (NAIH, CNIL, ICO, Garante) publish lists of processing types that mandate a DPIA. The app triggers at least three of those criteria:

(1) Article 35(3)(b), large-scale processing of special-category data (biometrics, sex/cycle data which is health data under Article 9);

(2) Article 35(3)(a), systematic and extensive evaluation of personal aspects based on automated processing, which is what an AI longevity coach with persistent memory does;

(3) per the CNIL's published list (https://www.cnil.fr/fr/liste-traitements-AIPD-obligatoire), processing of health data is on the mandatory-DPIA list. Without a documented DPIA, the controller has not formally identified the risks, the mitigations, and the residual risk acceptance, and cannot demonstrate Article 35 compliance to a regulator. The DPIA is also the document that decides whether prior consultation with the supervisory authority under Article 36 is needed (it is, if residual risk remains high after mitigations).

Launching without a DPIA on a special-category plus AI-profiling product is itself a GDPR violation (fines up to 2% of global turnover under Article 83(4)(a)). For a health-adjacent product the DPIA is also the controller's primary defence: it documents the risk model, the mitigations chosen (encryption, RLS, photo auto-purge at 90 days per `settings.tsx:577-582`, AI-output safety rails), and the conscious risk acceptance. Without it, in any post-launch incident (data breach, harm-from-coach-output, ATO with cycle-data leak), the controller has no Article 35 documentation to show that risks were considered and mitigated proportionally. The DPIA is also the natural place to document the AI-output limitations and the not-medical-advice posture, material that overlaps with the ToS (LEG-002) and with the eventual AI Act high-risk classification analysis (domain-compliance dimension).

EU law requires a formal 'risk assessment' document before launching a product that processes health-adjacent data and uses AI to profile users, both of which your app does. The assessment lists what could go wrong, what you have done to prevent it, and what risk remains. It takes 1-2 days to draft from a template and protects you significantly if anything ever goes wrong post-launch.

1. Use the CNIL PIA tool (free, https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protection-impact-assesment) or the ICO DPIA template to draft a DPIA covering: each data category (auth, profile, biometric photos, body measurements, cycle data, coach conversations, safety events), each processing purpose, each subprocessor, the legal basis (Article 9(2)(a) explicit consent for biometric and cycle data; Article 6(1)(b) contract for service delivery), the risks (re-identification, ATO with special-category exposure, AI-output harm, cross-border-transfer surveillance risk), the mitigations (encryption, RLS, auto-purge, safety rails, regional Supabase hosting), and the residual risk with the controller's sign-off.
2. For the AI coach output specifically, document: model used, intended purpose (advisory only), tested failure modes (medical mis-recommendation, suicide-risk mishandling, false positive on safety events), human-in-the-loop expectation (none, explicit), risk-mitigation through safety-rail prompts.
3. Review the DPIA quarterly and after any material change (new subprocessor, new processing purpose, new model).
4. If the DPIA concludes residual risk is high (e.g. for the mental-health-adjacent coach surface), consult the supervisory authority (NAIH in HU) under Article 36 before launching that processing.
5. Keep the DPIA internal but reference its existence and date of last review in the privacy policy (LEG-001).

M — 1–3 days

• https://gdpr-info.eu/art-35-gdpr/
• https://gdpr-info.eu/art-36-gdpr/
• https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protection-impact-assesment

The Record of Processing Activities is the controller's internal inventory: for each processing activity, the purpose, the categories of data subjects and personal data, the categories of recipients (including subprocessors), the international-transfer mechanism, the retention period, and the technical/organisational security measures. It is the document a DPA asks for first in any audit. It overlaps significantly with the DPIA (LEG-008) and with the subprocessor inventory (LEG-004), the same source data, different presentations. Without it, the controller cannot answer basic regulator questions ('Show us your processing activities') and cannot internally check that all subprocessors have signed DPAs (LEG-004) or that all special-category processing has a DPIA (LEG-008).

An Article 30 finding is usually not, by itself, a launch-blocker in the way the privacy policy gap is, but if a regulator opens an investigation for any other reason, the absence of a Record of Processing is an immediate aggravating factor in the fine calculation under Article 83(2). Operationally, the Record is also the source-of-truth document new team members read to understand 'what data does this system actually hold and why', without it, every onboarding takes longer and the controller's risk posture drifts over time.

EU law requires a one-page internal inventory called 'Records of Processing', basically a list of what data you collect and why. For most small companies this is optional, but because your app processes health-related data, the exemption does not apply to you. It is a 1-day task using any template (the UK and French regulators publish free ones).

1. Use the ICO controller template (https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/documentation/) or the CNIL template as a starting point.
2. Populate one row per processing activity: 'User account management', 'Biometric photo analysis for body composition', 'Coach conversation AI inference', 'Cycle tracking', 'Push notifications', 'Weekly report generation'. For each row record: legal basis (Article 6 plus Article 9 sub-paragraph if applicable), data categories, retention, subprocessors, transfer mechanism, security measures (encryption, RLS, auto-purge).
3. Store the document outside the repository in the controller's compliance folder; reference its existence in the privacy policy.
4. Review and update quarterly, and on every new feature that touches personal data.
5. The Record, the DPIA (LEG-008), and the subprocessor list (LEG-.
6. should all reconcile, keeping them in one shared workbook is easier than maintaining three documents that drift apart.

S — under ½ day

• https://gdpr-info.eu/art-30-gdpr/
• https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/documentation/

Today the app does not place any cookie or storage that requires consent under the ePrivacy Directive Article 5(3): the localStorage uses are either authentication (exempt) or user preference (exempt). The 'sidebar_state' cookie is UI-state, also exempt. So as of audit date, the absence of a consent banner is technically compliant. However: (a) the privacy policy gap (LEG-001) means the controller is still required by GDPR Article 13 to disclose all uses of cookies/storage, even strictly-necessary ones, in the policy, which currently does not exist; (b) the moment any analytics, A/B test framework, marketing pixel, or session-replay tool is added (very common in early-launch optimisation), the absence of a consent mechanism becomes an immediate violation; (c) the Lovable platform itself may inject preview-mode telemetry or analytics into the deployed bundle that is not visible in this repo's source, this should be verified with Lovable. The DPC, CNIL, and Garante (Italian DPA) have all issued fines for non-strictly-necessary cookies fired pre-consent in the past 24 months.

Today: no fine exposure for the consent-banner gap specifically (the absence of trackers makes it moot). Forward-looking: the first PR that adds Plausible, PostHog, GA4, Sentry-with-session-replay, Hotjar, or any similar tool will silently put the app out of compliance. Without a consent framework already in place, that PR will not include a consent gate, the team will have to retrofit one under pressure. A consent banner added late is also a UX-regression event (drops trial-signup conversion 5-15 percentage points typically), better to design it in from day one. For Lovable platform telemetry: if Lovable injects anything analytics-like into production builds (not just preview builds), that is currently uncovered.

Right now your app does not use any cookies that require asking the user, so technically you do not need a 'Accept Cookies' banner today. But the moment someone adds any analytics tool (Google Analytics, Plausible, error monitoring with session replay, etc.) you immediately need one. It is much easier to put a simple consent mechanism in place now while the surface is small than to retrofit it later. Worth a 1-day investment.

1. Confirm with Lovable whether the production build injects any first-party analytics or telemetry that is not visible in this repo's source; if it does, classify each one as strictly-necessary or not.
2. Adopt a lightweight consent framework now, while the surface is empty. Options: (a) Klaro (open source, ~10 KB, EU-friendly), (b) Cookiebot/iubenda (managed, paid), (c) build a custom 3-button banner (Accept all / Reject non-essential / Settings) wired to a `consent` localStorage key consumed by any future analytics initialiser.
3. Document the storage inventory inside the privacy policy: sb-<projectid>-auth-token (localStorage, strictly necessary), i18nextLng (localStorage, preference), country_autosuggested:<userid> (localStorage, preference), sidebar_state (cookie, UI-state), __lovable_token (sessionStorage, platform-preview).
4. Adopt a convention: any third-party SDK added to the app (analytics, A/B, marketing) must be initialised inside an if (consent.analytics) gate, gated on the consent state, NEVER eagerly loaded on app boot.

S — under ½ day

• https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32002L0058
• https://klaro.org/
• https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-082020-targeting-social-media-users_en

The European Accessibility Act (Directive 2019/882) became enforceable on 28 June 2025. It applies to e-commerce, banking, transport ticketing, e-books, and 'consumer-facing services' provided in the EU market, a longevity-coach B2C app likely qualifies as a consumer service. The reference standard is EN 301 549, which incorporates WCAG 2.1 Level AA. Concrete gaps in this codebase that an audit would surface: (a) clickable <div> elements without role='button', tabIndex={0}, and a matching onKeyDown for Enter/Space, fails 2.1.1 Keyboard, 4.1.2 Name-Role-Value; (b) content images with alt='', fails 1.1.1 Non-text Content for the academy thumbnails specifically (decorative-only intent should be re-evaluated per image); (c) absence of a `prefers-reduced-motion` accommodation around framer-motion animations, fails 2.3.3 Animation from Interactions (AAA, not strictly AA-required but commonly bundled into compliance scopes); (d) no published accessibility statement, required by the EAA in itself, separate from the technical conformance. Note: this finding is heuristic, a full WCAG conformance audit is a multi-day manual project per page and is out of scope for static repo inspection.

Since 28 June 2025, the EAA is enforceable across the EU; member states are starting to designate enforcement bodies and reporting routes. Penalties vary by member state but range from low-five-figure fines to product withdrawal orders. For a longevity-coach app, the user demographic likely includes age-50+ users who are more affected by accessibility shortcomings (lower vision acuity, reduced fine motor control, increased screen-reader use). Beyond compliance: a non-accessible app silently loses 15-20% of the addressable market (the share of EU adults with a recognised disability or significant access need). The fix scope here is moderate, converting clickable divs to buttons, fixing alt text, adding focus-visible utilities, measured in days, not weeks.

The EU Accessibility Act became enforceable in June 2025 and applies to consumer-facing apps like yours. There are real but fixable gaps in the current build: some buttons are not keyboard-usable, some content photos do not describe themselves to screen-reader users, and the animation-heavy interface has no 'reduce motion' option. None of this is blocking on its own, but it should be fixed in the first few sprints and an accessibility statement should be published.

1. Run an automated baseline (axe-core CLI, Lighthouse Accessibility, or @axe-core/playwright) to enumerate the actual WCAG 2.1 AA gaps and prioritise.
2. Replace clickable divs with <button> (or <Link>) elements throughout, the 23-file list above is the starting hit-list. Where a <div> must stay, add role='button', tabIndex={0}, and onKeyDown handling Enter/Space.
3. Audit every alt='' instance: if the image conveys content (academy thumbnails, biotwin avatars, body photos), provide descriptive alt text; if it is truly decorative (next-to-text icon), keep alt='' and ensure the adjacent text is the screen-reader source.
4. In `styles.css`, ensure a high-contrast focus-visible:outline rule applies to all interactive elements.
5. Wrap heavy framer-motion animations in a useReducedMotion() check (the library exports it) and skip-or-shorten when the user has prefers-reduced-motion: reduce.
6. Audit colour contrast: the warm cream/hazelnut palette (var(--espresso) on var(--cream)) likely passes, but the muted-text (text-muted-foreground at 11px/10px in many places, see settings.tsx:.
7. should be verified at 4.5:1 minimum contrast.
8. Publish an accessibility statement at /accessibility (linked from the footer), the EAA requires a public statement of conformance, gaps, and the feedback mechanism for users to report issues.
9. Add accessibility checks to CI (axe-core plus Playwright).

L — 1–2 weeks

• https://ec.europa.eu/social/main.jsp?catId=1202
• https://www.w3.org/WAI/standards-guidelines/wcag/
• https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf

The EU E-Commerce Directive 2000/31/EC Article 5 (transposed into national law as Telemediengesetz Section 5 in Germany, Ekertv. Section 4 in Hungary, etc.) requires that any commercial online service provider publish, in an easily accessible form, the provider's name, geographic address, electronic contact, registration number (where applicable), VAT number (where applicable), and supervising authority (where applicable). For Germany the requirement is enforced strictly, Impressumspflicht violations are routinely the subject of cease-and-desist letters (Abmahnung) from competitor law firms. For Hungary, the same information must be available before any contract is concluded (Ekertv. Section 4). The app's signup screen is effectively a contract-conclusion moment (the user agrees to the not-yet-existing Terms of Service per `auth.legal`), so the Impressum/Imprint must be linked from there at minimum. None of this exists.

For German users, the immediate exposure is Abmahnung-style cease-and-desist letters from law firms specialising in finding Impressum gaps; typical settlement costs are EUR 500-2000 each plus a corrective Impressum. For Hungarian users, the consumer-protection authority can issue fines for missing Ekertv. Section 4 disclosures. Reputational impact: missing Impressum is an immediate red flag in any due-diligence review (B2B partners, investors). The fix is trivial (add a footer with name, address, email, VAT-ID, EU OS-platform link) but must be in place before German/Hungarian launch.

German and Hungarian law require every commercial website to publish a small 'company info' block (legal entity name, address, contact email, VAT number) that users can reach from every page. Your app supports both German and Hungarian as launch languages, so this is in scope. The fix is a 1-hour task once you have the company details to fill in.

1. Create `src/routes/impressum.tsx` (or `src/routes/imprint.tsx` with a localized title) rendering, in all 6 supported languages: legal entity name, geographic address, registration number (e.g. HU cegjegyzekszam), VAT number, email address, telephone number if applicable, name of the legally responsible person, supervising authority where applicable.
2. Add a footer component (`src/components/Footer.tsx`) that renders on every page with links to /impressum, /privacy, /terms, /accessibility.
3. For EU consumer-disputes, add the EU Online Dispute Resolution platform link (https://ec.europa.eu/consumers/odr), mandatory under Regulation (EU) 524/2013 when offering goods/services to consumers.
4. If the controller is a Hungarian entity, include the NAIH (Nemzeti Adatvedelmi es Informacioszabadsag Hatosag) reference as the data-protection supervisory authority.
5. For the German market specifically, follow the structure used by reputable German SaaS apps (the canonical layout is well-documented).

S — under ½ day

• https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32000L0031
• https://www.gesetze-im-internet.de/tmg/__5.html
• https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32013R0524