How we protect your data

Couple’s Weekly Check-in stores some of the most personal information two people can share with a piece of software: appreciations, frictions, the things you’re each carrying. We treat privacy as a design constraint, not a marketing line. This page lays out exactly what we do, in plain language, so you can verify our claims.

Encryption at rest

Every check-in response, calm recap, weekly agreement, agreement rejection and shared memory is encrypted with AES-256-GCM (an authenticated encryption algorithm) before it touches the database. The encryption key is held by the application and never written to the database. Even a full database dump would yield only ciphertext.

Encryption in transit

All traffic to and from the app runs over HTTPS. We send a Strict-Transport-Security header that opts your browser into HTTPS for two years, including subdomains.

Two-factor authentication on every sign-in

Every sign-in with an email address and password requires a second factor. There is no way to sign in with a password alone. By default we email a 6-digit code to your address each time, so the second factor works for everyone with no setup, no extra app, and no recovery codes to lose track of. If you prefer faster sign-ins you can enrol an authenticator app (TOTP) under Settings, and even then you can always fall back to the email code if your phone isn’t to hand.

Auto-deletion you control

In Settings you can enable auto-deletion and choose any retention window between 14 days and 730 days (two years). Once enabled, a daily job permanently removes any check-in older than your chosen window, including all responses, agreements and rejection history. Auto-deletion is off by default. Turning it on or changing the value requires both partners to agree.

On-demand deletion

You can also delete an individual check-in, leave the couple, or delete your account at any time. Deletions are immediate and cascading. Nothing is kept in a soft-deleted limbo.

Data export (GDPR Article 20)

Settings → Download my data exports your full history as a decrypted JSON file you can keep, archive or move elsewhere. We never charge for this and we never gate it.

No analytics, no AI training

We don’t run Google Analytics, PostHog, Sentry, Segment, or any other behavioural tracker. We don’t set advertising cookies. Your check-in content is never used to train any AI model, not ours and not anyone else’s.

The one exception is Google Ads conversion measurement: if you arrive from a paid Google ad, we ask for your consent on a banner and, only if you accept, capture the click identifier from your URL and send a sign-up signal server-to-server to Google. No cookies, no client-side tag, no cross-site tracking. You can withdraw consent any time via “Privacy choices” in the footer. Full detail in the privacy policy.

Sub-processors

The following third parties receive limited data so the product can function:

• Railway hosts the application and the PostgreSQL database. Sensitive fields are encrypted before they are written to the database, so Railway only ever sees ciphertext for those columns.
• OpenAIreceives decrypted check-in responses at the moment your weekly recap or agreement is generated. OpenAI’s API terms forbid using API inputs to train their models.
• Resend sends transactional email (sign-in codes, reminders, deletion confirmations, partner notifications). It receives your email address, name and email content, and never receives check-in content.
• Google Ireland Limited (Google Ads) only kicks in for visitors who arrive via a paid Google ad and accept the consent banner. It receives either the original click identifier (gclid, gbraid or wbraid) or a SHA-256 hash of your verified email address, plus a conversion name and timestamp, sent server-to-server when you verify your email or create a check-in space. Never receives check-in content, your cleartext email address, or any browsing behaviour.

When we enable paid subscriptions we will additionally engage a payment provider. It will be named here and in the privacy policy at that point.

Browser-level protections

Every page response sets a Content-Security-Policy, X-Frame-Options: DENY (so the app cannot be embedded in another site to phish you), X-Content-Type-Options, Referrer-Policy and a Permissions-Policy that denies camera, microphone and geolocation.

PII-safe error logging

Server-side error logs never serialise check-in content, agreements, private risks or other sensitive fields. We log only the error name, a short message, and a small whitelist of identifiers (e.g. couple ID) so we can debug without leaking content.

Reporting a vulnerability

If you find a security issue, please email weeklycheckinapp@gmail.com rather than filing a public issue. We aim to acknowledge reports within two business days.