Privacy Policy
Mental Offload ("the App", "we", "us", or "our") helps couples manage household responsibilities. This policy explains what personal data we process, why we process it, who receives it, how long it is kept, and your rights.
The App keeps a working copy of household data on your device using Apple SwiftData so it can remain responsive and tolerate temporary connection loss. The public launch service also requires a Mental Offload account and synchronizes supported data through Supabase. Local-only builds are development configurations, not the public launch architecture.
1. Data Controller
Name: Adam Khelifi
Location: Denmark
Contact: support@mentaloffload.app
2. Data We Process
2.1 Data kept on your device
| Data | Examples and purpose |
|---|---|
| Names and preferences | Your name, partner name, language, appearance, default owner, view mode, and notification choices. |
| Tasks and subtasks | Titles, descriptions, due dates, status, ownership, work type, estimates, actual time, completion state, and recurrence. |
| Responsibilities and categories | Titles, descriptions, category, ownership assignments, and active/archive state. |
| Routines and routine blocks | Titles, descriptions, schedules, reminders, start times, durations, owners, order, and notes. |
| Appointments | Titles, descriptions, location, time, all-day state, audience/owner, recurrence, and reminder preferences. |
| Offload data | Quick-capture items, notes, and task-draft metadata used before an item becomes a synced entity. |
| Technical state | Session, queue, migration, analytics-choice, diagnostics-queue, and other app-operating state. |
Offload items and Offload task drafts are local by default and are not in the current active domain-sync table set. If you convert one into a task, responsibility, routine, or appointment, the resulting entity can be synchronized. A full data export includes the current device's Offload queue/drafts in a local JSON snapshot and may also include historical server-side Offload rows in the separate cloud ZIP.
2.2 Account, profile, and couple data
The launch service uses Sign in with Apple and Supabase authentication. We process:
- Apple-provided user identifier, identity token, and email when Apple makes it available;
- Supabase user ID, account email, session tokens, and session expiry;
- couple and membership identifiers, role, and status;
- your name and partner name;
- invited partner email, invite token, expiry, status, and acceptance details.
Authentication tokens are stored in the device Keychain. Supabase receives the Apple identity token and nonce to establish the authenticated session.
2.3 Cloud-synchronized household data
The current active sync set includes categories; responsibilities and assignments; recurrence rules; routines and routine blocks; tasks and subtasks; appointments and per-member appointment reminder preferences; and work-follow records used for notification delivery.
These records include stable entity, user/member, and couple identifiers, relevant content and scheduling fields, timestamps, soft-deletion state, and actor metadata. Cloud writes also create an item-change history containing changed fields and old/new values or row snapshots so changes can be synchronized and audited.
2.4 Notifications
If you enable notifications, the App sends Supabase the APNs device token and environment; notification enablement and delivery modes; digest, quiet-hours, daily-brief, and partner-brief preferences; time zone; language; your name; and partner name.
Some transmitted preference fields are not yet used by the server, but they still leave the device and are covered by this policy. Apple Push Notification service receives the notification payload. A partner notification can include the actor's display name and routing identifiers, but Mental Offload does not send the task title in that payload.
2.5 Billing
When billing is enabled and you buy a subscription through Apple, we process Apple transaction/original-transaction identifiers, plan and entitlement status, billing period, grace/revocation state, and account/couple linkage. Apple receives a Mental Offload user UUID as the StoreKit app-account token. We do not receive payment-card details or Apple account credentials.
2.6 YAP voice processing
YAP is active and runs only when you choose the voice action, grant microphone access, record, and submit audio.
The App sends the YAP Supabase Edge Function the temporary audio recording, active responsibility titles, transcription language, a stable installation identifier, and account authentication when signed in. The Edge Function sends the audio and language to OpenAI for transcription, then sends the full transcript and responsibility titles to OpenAI for structured extraction.
Mental Offload does not persist raw audio or the full transcript in Supabase. The temporary local audio file is deleted after processing or cancellation. Extracted Offload item titles are stored locally; if no item is extracted, the App can use up to the first 80 transcript characters as a local fallback title. OpenAI's provider-side retention rules still apply. OpenAI states that API data is not used to train models unless the customer opts in, but abuse-monitoring logs and application state can be retained according to endpoint and project data-control settings.
2.7 Optional first-party usage analytics
The App does not record or send product/performance analytics until you explicitly enable them. If enabled, it sends allowlisted events to Supabase to understand feature use, onboarding, and performance.
| Data | Examples |
|---|---|
| Product interaction | Screen/flow/step, task created or completed, routine/appointment action, YAP outcome, paywall, auth/invite/sync/export action. |
| Performance | Measurement name, duration, threshold, counts, and whether a path was slow. |
| Technical context | App version/build, OS, device family, locale, environment, timestamp, and session ID. |
| Pseudonymous identity | Server-side keyed hashes derived from installation, verified user, and verified couple identifiers. |
Raw installation and reported couple identifiers travel to Supabase so the server can validate and hash them; authenticated requests also expose the verified account to Supabase. Analytics rows store keyed hashes. Raw IP addresses are used transiently to derive rate-limit hashes.
Analytics rejects sensitive property names and redacts common bearer tokens, JWTs, token query values, and email patterns. It is designed not to include names, task/description content, notes, responsibility/routine titles, invite tokens, YAP audio, or transcripts. You can disable analytics in Settings; disabling stops capture and clears pending local events.
2.8 First-party error, crash, and hang diagnostics
Diagnostics are separate from optional analytics and are enabled for reliability and security. The App can send Supabase error message/type/domain/code/fingerprint; severity and handled/fatal state; source location; bounded stack, underlying error, context, breadcrumb, and tag data; app/OS/device/locale/time-zone context; session and stable installation identifiers; verified user/couple identifiers for some signed-in errors; and MetricKit crash, exception/signal/termination, and hang summaries.
MetricKit reports omit current user/couple attribution, current breadcrumbs, and bearer token, but still include installation/session and device diagnostics. Automated sanitizers remove credential-shaped keys and common bearer/JWT/query-token/email patterns and truncate payloads. We do not intentionally include household content, but automated redaction cannot guarantee removal of every arbitrary name, title, note, transcript fragment, or other value if a failing path placed it in an error, context, or breadcrumb.
2.9 Website waitlist
If you join the website waitlist, we process your email, consent record, browser locale, signup source, page path, request/confirmation timestamps, request count, and confirmation status. IP and email-domain values are used transiently to derive rate-limit hashes. Resend receives the email address and confirmation message when confirmation delivery is enabled.
If an address was previously archived or removed, another public form submission records a rejoin request but does not reactivate the address. We use an atomic delivery claim to suppress concurrent duplicate owner-verification/support messages, and reactivation requires confirmation through support. If delivery fails or the provider's delivery result is uncertain, a later explicit rejoin request may trigger another verification message.
2.10 Data exports
A full export requires a signed-in session and fresh Sign in with Apple authorization. Supabase first generates a private cloud ZIP containing relevant account/profile, couple, billing, synchronized household, requester-visible current or historical server Offload, item-history, requester notification-delivery, analytics, diagnostic, retained project/section, and visible orphan recurrence-rule/history records.
After download, the App creates a JSON snapshot of the current device's local work, preferences, actual Offload queue/drafts, and routine occurrence completions/owner overrides. The App packages that JSON beside the untouched cloud ZIP and a top-level manifest in one ZIP; the local JSON is created on-device and is never uploaded during export preparation.
The export excludes authentication/session/APNs/invite bearer tokens, partner-private task, appointment, reminder, history, and notification data, pending task graphs whose current cloud visibility cannot be proven, other members' notification-delivery rows, service secrets, internal quota and sync-repair rows, provider retry details, raw Apple event payloads, diagnostic stacks/context/breadcrumbs, and selected external billing identifiers. The App requires a fresh successful visibility refresh before it packages device data. The signed cloud link lasts 15 minutes; the private server file expires after 72 hours and is removed by server cleanup. App-managed temporary cloud/full ZIPs become eligible for deletion after 72 hours and are removed during a later download/export cleanup pass. Copies you save or share remain under your control.
2.11 Data we do not collect or use
- We do not collect precise or coarse location, contacts, health/fitness data, or browsing/search history.
- We do not receive payment-card details.
- We do not use IDFA, advertising SDKs, data brokers, targeted advertising, or cross-app/cross-website tracking.
- We do not sell or rent personal data.
- We do not use third-party analytics or crash-reporting SDKs. We do use the first-party analytics and diagnostics disclosed above.
- The website does not use analytics or advertising cookies and self-hosts its visual assets.
- The Apple privacy manifest declares tracking as false.
3. Why We Process Data
| Activity | GDPR Article 6 basis | Reason |
|---|---|---|
| Account, sync, household features, preferences, notifications, exports, and billing | Contract performance, Art. 6(1)(b) | Needed to provide requested App features. |
| YAP voice processing | Contract performance, Art. 6(1)(b) | Necessary to provide voice-to-task conversion when you actively request and submit a recording. Microphone permission is a device permission, not a separate GDPR consent record. |
| Website waitlist and launch emails | Consent, Art. 6(1)(a) | You choose to join and receive messages. |
| Optional usage analytics | Consent, Art. 6(1)(a) | No capture occurs until you explicitly enable it. |
| Error/crash/hang diagnostics and abuse prevention | Legitimate interests, Art. 6(1)(f) | Secure, diagnose, and improve service reliability with minimization and redaction. |
| Couple invitation email | Legitimate interests, Art. 6(1)(f) | Delivers an invitation you ask us to send. |
| Legal, tax, dispute, and fraud records | Legal obligation, Art. 6(1)(c), or legitimate interests, Art. 6(1)(f) | Comply with law or establish, exercise, or defend claims. |
The GDPR is supplemented in Denmark by the Danish Data Protection Act. If processing genuinely requires consent, you may withdraw it without affecting earlier lawful processing.
4. Recipients and Processors
Supabase
Receives account/authentication, synchronized household/couple, item-history, notification, billing, waitlist, transient YAP, optional analytics, diagnostic, and export data for authentication, storage, Edge Functions, sync, notifications, analytics/diagnostics, abuse prevention, and exports. The configured Mental Offload region is AWS eu-west-1, Ireland. Supabase privacy policy.
Apple
Receives Sign in with Apple requests and credentials, purchase requests and app-account token, and APNs notification payloads/device tokens for authentication, payments/subscriptions, and push delivery. Apple acts as an independent controller for payment services. Apple privacy policy.
OpenAI
Receives YAP audio/language for transcription and transcript/responsibility titles for structured extraction. OpenAI privacy policy.
Resend
Receives authentication, partner invitation, waitlist, operational-alert, and support email addresses and the email content needed for transactional delivery or support receipt. Support messages sent to support@mentaloffload.app are forwarded as bounded plain text to the operator's private support inbox; attachments remain in Resend Receiving. Mental Offload keeps only a minimal 30-day webhook-delivery record with provider identifiers, event type, status, and timestamps, not message bodies or addresses. The selected sending region is AWS eu-west-1 in Ireland; Resend states that account data, email metadata, logs, and API records remain stored in the United States. See the Resend privacy policy and Resend DPA.
Google Gmail
Receives the support sender address, subject, and bounded plain-text message body forwarded from Resend so the operator can read and answer support mail. Attachments are not forwarded. See the Google privacy policy. The operator approved this production support-inbox route on July 21, 2026. It remains subject to the applicable Google account terms, retention rules, and international-transfer safeguards; that approval is not represented as execution of a formal Google Cloud data-processing agreement.
We do not sell, rent, or trade personal data. Some processors may use infrastructure outside the EEA. Applicable data-processing agreements and transfer safeguards, such as adequacy arrangements or Standard Contractual Clauses where required, must be verified as part of the public-release checklist. YAP or email processing must not be treated as launch-ready until that verification is complete.
5. Retention
| Data | Retention |
|---|---|
| Local App data | Until you delete it through the App or remove the App, subject to copies you export/share. |
| Active cloud data | While your account/service relationship is active and as needed to provide the service. |
| Soft-deleted synchronized rows | A cleanup function uses a 45-day cutoff, but no automatic production schedule was verified. Do not treat the limit as guaranteed until deployment is verified. |
| Invite tokens | Default expiry is 72 hours; expired rows may remain until operational cleanup. |
| Waitlist | Until you withdraw, unsubscribe, request deletion, or the waitlist is no longer needed. |
| Billing/legal records | As needed for subscription administration, disputes, tax, fraud prevention, or legal duties. |
| Usage analytics | Up to 13 months, then deleted or aggregated. |
| Diagnostics | No longer than reasonably necessary. Six months is the intended automatic ceiling, but the cleanup migration is not yet production-verified. |
| Terminal notification event history | The pending cleanup uses 90 days for sent and skipped rows. pending, sending, and failed rows are not age-deleted. The cleanup is not yet production-verified. |
| Item-change history | The pending cleanup uses a 12-month ceiling. It is not yet production-verified. |
| YAP audio/transcript in Mental Offload systems | Temporary processing only; not persisted in Supabase. OpenAI endpoint/project retention applies. |
| Completed Resend webhook ledger | 30 days. Support message bodies and addresses are not stored in this ledger. |
| Data-export ZIPs | Server cloud file expires after 72 hours and is removed by server cleanup; signed cloud link lasts 15 minutes. App-managed temporary cloud/full ZIPs become eligible after 72 hours and are removed during a later download/export cleanup pass. |
| Authentication session | Until expiry, sign-out, account deletion, or revocation. |
Account deletion has role-specific shared-data effects:
- A partner who deletes their account deletes that Auth account and their couple-scoped private tasks, private appointments, Offload data, settings, and membership. Shared work assigned to that partner remains for the owner as shared work without an assigned member.
- An owner who deletes their account deletes that Auth account and the complete couple data graph, including both members' couple-scoped private data. The linked partner's Auth account is not deleted, but it is disconnected from the deleted couple.
- Completed server data-export archives that are still represented by request metadata are deleted through the Storage API before the related account or couple rows are removed. Database teardown is refused while a discoverable archive path remains.
- Sign in with Apple token revocation is attempted for the requesting user when fresh authorization is supplied. App Store subscription cancellation remains a separate action managed through Apple.
Backups may retain deleted records for a limited recovery period and are not restored to bypass a valid deletion request.
6. Your Rights
Subject to the GDPR and applicable law, you may have rights to access, correct, delete, restrict, port, or object to processing; withdraw consent; and complain to a supervisory authority.
Use Settings > Manage Account > Request Data Export for the full cloud-plus-device export. Use the in-app deletion controls to initiate local or account deletion where available, or contact support@mentaloffload.app. Disable optional analytics in Settings. For YAP, do not submit another recording. For waitlist mail, reply to the confirmation message or contact us; there is currently no automated unsubscribe endpoint.
For Denmark, the supervisory authority is Datatilsynet.
7. Security
Controls include TLS in transit, iOS Data Protection, device-only Keychain session storage, Supabase Row-Level Security, scoped private export storage, short-lived signed links, rate limiting, server-side identity verification where required, allowlisted analytics, diagnostic sanitization, and secrets managed outside source code.
Not every endpoint uses a user JWT: public waitlist, anonymous/identified YAP, analytics ingestion, and diagnostic ingestion use purpose-specific publishable-key, bearer, installation, validation, rate-limit, or secret controls. Authenticated household, billing, and export operations require verified account context and enforce their own authorization rules.
8. Children
Mental Offload is intended for adults aged 18 or older. We do not knowingly collect personal data from children. Contact us if you believe a child has supplied data.
9. Additional regional information
For California and other US residents, categories processed can include identifiers, commercial information, internet/electronic activity, audio, diagnostics, user content, and product inferences. We do not sell or share personal information for cross-context behavioral advertising.
Residents of the UK, Switzerland, Canada, Australia, and other jurisdictions may have comparable access, correction, deletion, objection, portability, or complaint rights. Contact us and we will assess the request under applicable law.
10. Changes
We may update this policy when the product, processors, law, or data practices change. We will update the date above and provide additional notice or request renewed consent where required.
11. Contact
Email: support@mentaloffload.app
Location: Denmark
We aim to respond to data-rights requests within one month, subject to lawful extensions.