Privacy

PendingOperator's legal name, address, and email

This document refers to the operator as “we” / “Evermore” throughout. Evermore (ever-more.app) is a wedding-planning and guest-coordination app: organizers (the couple, and optionally a wedding planner) run a wedding's private space; guests join it to see schedules, contribute photos/videos, chat in groups, RSVP, and browse a gift wish list.

Each category below is grounded in what the app actually stores and who can read it.

2.1 Account data (email, display name)

Organizers provide an email address and password, and a display name. Guests provide a display name only (see 2.2). The email/ password pair is never shown to other members; the display name is visible to other members of any wedding a person belongs to. Legal basis: performance of a contract (Art. 6(1)(b) GDPR).

The sign-in address is also used to send you account messages about your own account — a link to verify the address, a link to reset your password, and a confirmation link when you change the address you sign in with (which is sent to the new address, so a typo cannot lock you out). These are sent by Google Firebase Authentication, our authentication processor; see §3. They are not marketing, they carry no tracking, and they cannot be turned off while the account exists, because they are how you keep access to it. You can change the address, change the password, and see whether the address has been verified, from Your account in the app.

2.2 Guest anonymous identities

A guest can get a full, persistent identity from a display name alone — no email, no password. This keeps onboarding at a party low-friction. A guest can later link an email/password to the same identity without losing any content. Legal basis: contract performance (Art. 6(1)(b)).

2.3 Participant records — including dietary and allergy data

Organizers maintain a guest/participant directory: name, lifecycle state, notes, table assignment, and — once answered — dietary selections from a closed vocabulary (vegetarian, vegan, pescatarian, halal, kosher, gluten-free, lactose-free, nut-allergy, other) plus a free-text dietary-notes field. This is used for headcounts, catering, and seating.

Allergy-adjacent entries can touch GDPR Art. 9 “special category” health data. The vocabulary is coarse and the purpose narrowly catering-related, which weighs toward this not being Art. 9 data in practice — but the free-text notes field could capture more than that.

PendingExplicit consent microcopy on the RSVP form, at the dietary/allergy fields— recommended, not yet implemented This would put the legal basis on solid Art. 9(2)(a) footing regardless of how the data is classified.

Visibility: organizer-only. Guests cannot read the participant directory at all, not even their own record, except through a constructed RSVP projection that omits internal notes.

2.4 Photos and videos of identifiable people

Guests and organizers upload photos and video clips into shared albums, each with an audience (couple, organizers, everyone, or a private group). Legal basis: contract performance for the product's core function; for other guests appearing in a photo they didn't upload, the basis is closer to the uploader's legitimate interest in documenting a shared event (Art. 6(1)(f)) — the app has no way to obtain consent from everyone who appears in a crowd photo, which is inherent to any group-photo product.

EXIF and location data. Most uploads are downscaled client-side before upload, and that re-encoding strips all metadata, including GPS location — this was done for upload speed, not privacy, but the effect is the same. There is a real fallback path (for files the browser can't decode, e.g. some HEIC files) where the original file — EXIF and any GPS data intact — is uploaded and served to that directory's audience untouched. This page states that honestly rather than claiming no location data is ever stored.

Any member who can see a directory can delete their own upload, permanently. Organizers can delete anything in directories they can see, or hide (reversible moderation, not deletion) any item.

2.5 Chat messages (group chat)

Text-only messages inside a private group. Legal basis: contract performance. Messages cannot be edited. A message can be deleted by its author or the group's creator — organizers outside a group cannot read or moderate that group's chat unless they are themselves a member.

2.6 Wishlist claims

A guest can claim a gift-registry item. Legal basis: contract performance. Organizers — couple included — are structurally denied read access to who claimed what, enforced server-side, so a surprise gift stays a surprise.

2.7 RSVP tokens and no-identity RSVP

Each invitation gets a random token; the app stores only its hash. A guest with the link can view and answer their household's invitation without ever creating an account. What's recorded: the fact and time of first opening the link, and the submitted answers — nothing else. No IP address, device fingerprint, or later-open tracking is recorded on this path, by design. Legal basis: contract performance.

2.8 Guest email addresses, entered by organizers

When organizers choose to have Evermore send a household's invitation by email, they type that household's email address(es) into the invitation. These are used for exactly three messages: the invitation itself, a reminder if the organizers ask for one, and a receipt confirming what was recorded after that household answers through their link. Nothing else is ever sent to them — no newsletter, no digest, no marketing of any kind.

Supplied by the organizer, not by the guest. Guests never type their own address into this system; every address in it was entered by the couple or a co-organizer, from an address book they already had. Legal basis: the organizers' legitimate interest in inviting their own guests (Art. 6(1)(f)), which is the same basis a paper invitation to a postal address would rest on.

Visibility: organizer-only, enforced at the database layer. A guest holding a valid RSVP link cannot see any address, including their own household's, and the addresses are not attached to any participant record.

Deleted with the invitation that holds them. An address lives on the invitation document and nowhere else, so deleting that invitation removes it entirely — there is no second copy to clean up. An organizer can also simply clear the addresses, or switch the household to another delivery mode, at any time. If you would rather not be emailed, asking the couple to remove your address is the direct and effective route.

Alongside these, Evermore also sends a notification to organizers' own account email addresses when a household answers. Each organizer can turn that off for each wedding separately.

2.9 Budget (organizer-only)

A wedding's budget configuration, expense line items, and receipt photos. Legal basis: contract performance. Visibility: organizer-only, unconditionally — no guest can read any budget data, regardless of role.

2.10 Technical / infrastructure logs

Standard request logs generated by the hosting and database infrastructure — IP address, timestamp, request path — for operating, securing, and debugging the service. Legal basis: legitimate interest (Art. 6(1)(f)).

What we do not collect: there is no analytics SDK, no ad-tech, and no tracking pixel anywhere in this product. The only persistent browser storage the app sets is the sign-in session, used purely to keep a person signed in.

The database is hosted in the EU (Firestore, multi-region eur3). File storage (photos, videos, receipts) is hosted in europe-west3. The application itself runs in europe-west4. The processor for all of the above is Google Cloud, under Google Cloud's standard Data Processing Addendum, which incorporates the EU Standard Contractual Clauses for any residual international transfer.

PendingConfirmation the operator has accepted Google Cloud's Data Processing Addendum, with reference/date

Sign-in and account messages — Google Firebase Authentication

Sign-in credentials are held by Google Firebase Authentication, part of Google Cloud and covered by the same Data Processing Addendum as the database. It is also the sender of the account messages described in §2.1 — address verification, password reset, and confirming a change of sign-in address. What it receives for those is the address itself and the link; no wedding content is ever in one.

Transactional email — Resend

Evermore sends invitations, reminders, RSVP receipts and organizer notifications through Resend (Resend, Inc.), acting as a processor. What Resend receives is: the recipient address, the subject line, and the message content — which, for an RSVP notification or receipt, includes the party's name, who is coming, any dietary selections and notes they gave, and any message they sent the couple. No analytics or tracking pixel is embedded in any message; the templates contain no images at all.

Message metadata and delivery logs are held in the United States. Mail is dispatched from Resend's Ireland region (eu-west-1), but Resend stores account data, message metadata and logs in the US regardless of sending region. This is a genuine departure from the all-EU footprint described above, and is stated plainly here rather than left to be discovered: sending a household an invitation means their email address, and the content of that message, are processed outside the EU. The transfer relies on Resend's Data Processing Agreement and the EU Standard Contractual Clauses it incorporates.

PendingConfirmation the operator has accepted Resend's Data Processing Agreement, with reference/date

No other third-party processors are used — no analytics vendor and no SMS provider. If another is added later, it will be listed here.

Honest baseline: there is no automated data retention or deletion policy today. Content persists indefinitely until manually deleted by a user or organizer.

PendingA defined retention period, or an explicit 'we keep it until you delete it' policy

What deletion does exist: any member can permanently delete a photo/video they uploaded; organizers can delete or hide media in directories they see; chat messages can be deleted by their author or the group's creator; a wishlist claim can be removed only by the claimant; organizers can delete a participant record; any member of a group (or any organizer) can delete the group.

4.1 Deleting your account

You can delete your account yourself, from Your account in the app, without asking us. It is immediate and final: there is no undo, no grace period, and no recoverable copy kept anywhere.

The policy is one sentence, applied without exception: records that exist only to represent you are removed; content that belongs to a wedding is kept with your authorship anonymized. Per category:

• Removed outright: your sign-in credential and the identity behind it; your profile record; every membership you hold, in every wedding; every group roster entry; and every wishlist claim — which returns the claimed item to unclaimed, so somebody else can bring the gift.
• Kept, with your authorship anonymized: photos and videos you uploaded and the files behind them; messages you sent in a group; and the albums, groups, events, invitations, wishlist entries, budget lines, budget receipts and task entries you created, plus any record of you as a payer. Your name and your identifier are replaced by a marker that resolves to no account and that nobody can ever claim. The reason is not convenience: a guest who uploaded forty photographs should not take the couple's wedding album with them when they go, and anonymizing severs the link to you — which is what erasure requires — without destroying somebody else's memories.
• Guest-list records an organizer created stay with that organizer. A participant record is the couple's planning data — name, dietary needs, RSVP answer — that their caterer and seating plan depend on, and most participants have no account at all. If such a record was linked to your identity, the link is removed and the record itself remains.
• A surviving wedding keeps its own name, and the couple names recorded on it, even where those are yours. A wedding is named after its couple; erasing that would leave every remaining member an unrecognisable wedding. If your membership marks you as one of the couple, you are told this before you confirm, and offered the alternative below.
• A wedding that would be left without any organizer is destroyed along with your account — with everything in it: its members, guest list, invitations, albums, photos and their files, groups and conversations, events, seating, wish list, budget and receipts. This is not optional. A wedding's creator is recorded permanently and only they can appoint a first organizer, so a wedding that loses its last organizer can never be given another one: it would be readable by its guests forever with nobody able to moderate or remove anything. Every such wedding is named to you before you confirm, together with the way to avoid it — make somebody else an organizer first. If your membership marks you as one of the couple, you may additionally choose, per wedding, to destroy a wedding that would otherwise survive; the default is to leave it standing.

One residue is disclosed rather than glossed: an uploaded file's storage metadata still carries the internal identifier of whoever uploaded it. Once the account is gone that identifier maps to nobody and is never re-issued to anyone else, so it cannot be resolved back to a person — but it is not rewritten, and this page says so.

Access control is enforced at the database layer, not just hidden in the interface — even a technically sophisticated visitor probing the API directly gets the same restrictions.

• Everyone content (the main photo gallery, wedding-wide chat/events) is visible to every member of the wedding, guest or organizer.
• Organizers content (the participant directory, invitations, seating, budget) is visible only to organizers.
• Couple content is visible only to organizers flagged as the couple themselves.
• A named group (e.g. a bachelor party) is visible only to that group's own members — being an organizer or the couple grants no access to a group's content, including, potentially, their own surprise party.

What organizers specifically cannot see, even though they run the wedding: who claimed which gift, and the content of any group they haven't personally joined.

If you are in the EU/EEA (or another jurisdiction with equivalent rights), you have the right to:

• Access the personal data we hold about you (Art. 15)
• Rectify inaccurate data — e.g. your display name, dietary information (Art. 16)
• Erasure (“right to be forgotten”) — exercised yourself, from Your account in the app, without contacting us; §4.1 states exactly what is removed, what is kept under an anonymized author, and why (Art. 17)
• Restrict processing in certain circumstances (Art. 18)
• Data portability for data you provided us, in a structured, machine-readable format (Art. 20)
• Object to processing based on legitimate interest (Art. 21)
• Withdraw consent at any time, where processing is based on consent, without affecting the lawfulness of processing before withdrawal
• Lodge a complaint with a supervisory authority — in Germany, your regional Datenschutzbehörde

To exercise any of these rights, contact us: PendingOperator contact email

We may update this policy as Evermore's features change. Material changes will be dated and, where reasonably possible, users will be notified.

Carried over from the source draft, so nothing here is quietly resolved by omission:

• Controller identity (name, address, contact) — pending, §1
• RSVP dietary-data consent microcopy — recommended, not built, §2.3
• Automated retention/deletion policy — none exists yet, §4
• EXIF/location metadata on the upload fallback path — stated honestly above rather than hardened yet, §2.4
• Google Cloud DPA reference — pending confirmation, §3
• Resend DPA reference — pending confirmation, §3
• Message metadata for transactional email is held outside the EU — stated honestly above rather than solved, §3
• No bounce handling: a mistyped guest address fails silently at the provider, and the organizer sees only that the message was accepted, §2.8
• German translation — this draft is English-only
• Legal review — this document has not been reviewed by counsel