Privacy

Who is responsible

This is run by Jacob Frusher, who can be reached at jacob@frusher.co.uk. It is a personal project, not a company.

For a wedding you create, you decide what goes into it.

It reaches a server only if you make an account. Then I hold your wedding in a database — encrypted at rest, walled off from every other account, but readable by whoever runs the server. That is described below, and it does not happen unless you choose it.

Where your wedding lives

In your browser. Guests, seating, the running order, the crew and the stationery are all stored on the device you are using, in IndexedDB, and nothing is sent anywhere by default.

You can use the whole application without any of it ever reaching a server. Making an account changes that — to plan on more than one device, with your partner, or with your planner — and so does publishing a link for your guests or your suppliers, which needs one.

What an account holds, and who can read it

An account exists so you and your partner can plan on separate devices. Making one stores your email address — there is no password, no profile, and no name field. Signing in with your email sends a six-digit code to that address; entering it is what proves it is you. If you choose Continue with Google or Continue with Apple instead, that company confirms who you are and tells the app your email address, along with the name on that account, which the sign-in service keeps with your account and the app never reads or shows. Google or Apple learn that you signed in here; neither ever sees your wedding.

Your wedding is then stored in a database as one document, encrypted at rest, with database rules that make it unreadable to any other account. Inviting your partner or your planner adds exactly that person, by the email address you name. Either of you can see everyone who has access, and remove your planner at any time.

Being straight about it: this is ordinary, well-guarded storage, not encryption I cannot undo. I do not read your wedding and there is no support tool that would let me browse it, but I administer the database, so I could. If that matters more to you than planning across devices does, use the app without an account — it is the default, and nothing leaves your browser.

Earlier versions are kept alongside the current one, so a mistake can be recovered rather than being final: one for every ten minutes each of you spends changing it, and past a month, one for each day it changed.

While more than one of you has the wedding open, each change reaches the others as it is saved. What travels to announce it is a version number, not the wedding; each device then fetches the change the way it fetches everything else. The others with it open see your email address and which page you are on — nobody outside the wedding does.

A planner can also keep a library of their own — card designs, rooms, running orders and checklists — to use again for other weddings. It is theirs alone: no other account can see it, and nothing personal goes into it, so no guests, no dates and no suppliers' names or numbers. It stays until they remove it or delete their account.

What a guest link contains

Deliberately less than the wedding does. A published link carries names and table numbers, and optionally the shape of the room. It does not carry email addresses, phone numbers, dietary requirements, notes, or anybody who has declined.

It is encrypted under a key that travels in the link's own fragment — the part after the # — which browsers never send to a server. What the server hands out is sealed; without the whole link, it cannot be read.

The key is also kept with your wedding on your account, so whichever of you changes the seating can keep the link current. That makes it exactly as readable to whoever runs the server as the wedding itself — which already holds everything the link does, and more.

There is only ever one live link per wedding, and it updates itself as seats change, so a link you have already given out stays correct. Taking it down deletes it outright.

What a supplier's link contains

Each supplier can be given a link to their own call sheet: when to arrive, which of their people are named, and their jobs with the times, places and dates — with the couple's names, the date and the venue. It carries no guests at all, and nothing of any other supplier's.

It is sealed the same way as the guest link, under a key in the link's fragment that is also kept with your wedding, and it updates itself as their jobs and times change.

It has one button, Confirm. Pressing it records when, against that link and nothing else, and that date shows on your wedding as the day they confirmed. Taking the link down deletes it outright, and it goes by itself if that supplier is removed from your wedding.

How long it is kept

A wedding on an account that is not written to for 24 months is deleted automatically, along with its history, its uploaded files, its guest link and its suppliers' links. That is long enough to cover an engagement, the wedding, and a year of still wanting the seating plan.

There is no backup that outlives this. When it is deleted, it is gone.

Deleting it yourself

Deleting your account is on the account page — signing in is what proves it is yours. It takes you off every wedding you are on, and deletes each one nobody else is still on, with its history, its files, its guest link and its suppliers' links, immediately. A wedding someone else is on stays with them, because it is their wedding too.

Leaving one wedding works the same way, for that wedding alone. Deleting your account also deletes your library, if you kept one.

Your own browser keeps its copy unless you choose otherwise, because withdrawing from a server is not the same as wanting to lose your seating plan. Signing out asks whether to remove it from the device; clearing this site's data in your browser removes it too.

Cookies, tracking and counting visits

No advertising, no tracking pixels, and nothing that follows you from one website to another.

On the hosted site — this one, not a copy somebody runs elsewhere — visits to each page are counted with Vercel Web Analytics, the host's own counter. For each page it records the page's address, the site the visit came from, the country, and the kind of browser, system and device. Before an address is sent, anything in it that is not simply the page is cut out: the token in a guest link, a supplier's link or an invitation, the id of a wedding, and everything after a ? or a #. Nothing from your wedding is in it — no guest, no name, no table.

The hosted site also sends the page's address to Vercel Speed Insights, to measure how quickly pages load. That address is cut the same way first.

It sets no cookie and stores nothing on your device. It tells one visit from another by a code worked out from the request, which changes every day, so a visit cannot be linked to one on another day or on another website. It is done on the basis of legitimate interest: knowing which parts of the site are used.

One cookie exists, and only if you sign in: it holds your session, which is what keeps you signed in between visits. It is not used to track you and there is nothing to opt into, because without an account no cookie is set at all.

The browser storage that is used — IndexedDB — holds your wedding, which is the thing you came here to work on. Nothing about you is stored for any other purpose.

Error reporting

When something breaks, a diagnostic report may be sent to Sentry, an error-monitoring service, so the fault can be found and fixed. Sentry is one of three services that run the hosted site: Vercel hosts it and counts visits, as above; Supabase holds the database behind accounts and sends the sign-in emails; and Sentry receives these reports.

It is configured narrowly and on purpose. No session recording, no personal data, and no console output — the tools log parts of the document while they work, and that is the guest list. Web addresses have their fragment removed before anything is sent, so the key in a guest link can never reach it.

This is done on the basis of legitimate interest: keeping the application working. It sets no cookies and reads nothing from your device.

Staying signed in

Signing in keeps a session in this browser until you sign out, so you are not asked for a link on every visit.

The practical consequence is worth stating: on a shared or borrowed computer, signing out matters. Anyone using that browser afterwards can reach the wedding.

Stories for the blog

If you email your wedding story for the blog, it is read by me and kept in my email while we agree what is published. Nothing goes up until you have seen the page and said yes, it carries only the names you choose, and it is changed or taken down whenever you ask. A story that is not published is deleted.

Your rights

Under UK GDPR you have rights of access, correction, erasure and portability. Most of them are already buttons rather than requests: 'Export backup' gives you the entire wedding as one file, 'Download my wedding' on the account page does the same from the server copy, and the delete buttons above remove it.

For anything else, or if you think something here is wrong, write to jacob@frusher.co.uk. You can also complain to the Information Commissioner's Office.

Changes

The date at the top of this page is the date these words last changed, and it is kept honest by a test that fails if the text moves without it.