Last updated 16 October 2026. What changed: the shop has a bag, kept on your phone or in your browser until you check out (*Your shop bag*); the shop can put a face in one of our drawings (*A face you put in one of our drawings*); Checkout in the app opens the payment page with a one-time code; the AI service that suggests things to do is now told what the crew is into and its budget band; every cookie is now listed; and any photo printed on a garment now needs your tick first, and a photo you added in the shop is deleted as soon as its order goes to the printer.
This is the whole thing. There is no second document, no "additional terms", and no paragraph that means the opposite of what it says. If something below is unclear, that is a bug in this page — write to us and we will fix the page, not send you a clarification.
This is written by the people who make Mayzee, about Mayzee, so it is the one place in the product where the mascot is not the one talking.
Who is responsible. Mayzee Ltd, a company registered in England and Wales, company number 17518721. Registered office: Newlands Terrace, 169 Queenstown Road, London SW8 3RL. How to reach us. info@mayzee.app.
Mayzee is a group-holiday app. A trip is a link; you open it, tap your name, and you are in. There is no sign-up, no password, and no email address.
So the only things we hold about you are the things you or your friends typed into a trip: a first name, what you voted for, what you spent, when your flight lands, and the photos you put in the scrapbook. It is kept so that the app can show it to the people on the trip, and for nothing else. It is not sold, not shared with advertisers, and not used to build a profile of you. There is no advertising, no third-party analytics or tracking SDK, and no tracking cookie. We do count which screens and buttons get used and which cities trips go to — in our own database, with no name, no trip and nothing you typed — and *Help improve the app* on the You screen switches that off (see *What the app counts*).
These are product decisions, not omissions, and they are the reason the list further down is as short as it is.
No account. Signing up is the friction that keeps groups in a WhatsApp thread, so there is no sign-up. That has a privacy consequence people usually pay for: we have no email address for you, no password to leak, and no way to recognise you across two different trips unless you tell us it is you.
Never a passport number, and never a scan. The app checks two things that catch people out at the gate — that a British passport was issued less than ten years before you arrive, and that it is valid for three months after you leave. Both are answerable from two dates. The number answers neither and would be the single most damaging thing in the database, so it is not collected. Nor is a photo of the passport page, an issuing country, or a name as printed.
Never your IP address. Cloudflare, which runs our servers, tells us the country and region a request came from. We read those two words and store them on the trip so we can tell where groups travel *from*, which is what a hotel in Krakow actually cares about. The IP address itself is never written down.
Never your contacts. Adding people to a trip means typing their names. The app has no access to your address book and never asks for it.
Never your location, live. The app does not use location services. It has no NSLocationWhenInUseUsageDescription because there is nothing to describe.
No tracking. Nothing about you leaves Mayzee for any advertising, measurement or data-broker purpose. The app shows no App Tracking Transparency prompt because there is nothing it would be asking permission for.
Everything below lives in one Cloudflare D1 database named mayzee and one Cloudflare R2 bucket named mayzee-moments.
Its name, its dates, where the group is going and every place anyone proposed, the trip's currencies and timezone, what kind of trip it is (stag, hen, family, and so on), a budget band if the organiser gave one, tags for what the group likes, the commitment rule ("enough of us by the 1st or it's off"), the savings target, and the share code itself.
Plus the country and region the trip was created from, taken from Cloudflare's own reading of the request. Not the IP. Not a street. "GB" and "England".
And how the trip was started, as one word: from a device already on another trip, from a postcard's page, or neither. Never which trip, and never who.
Destinations proposed and the notes on them; votes, objections, delegations and abstentions; which dates were put up for the trip and, for each one, whether you said you could make it; itinerary items with their titles, notes, times and who is going; everyone's travel legs — mode, times, airports or stations, flight or train number, carrier, pickup point, spare seats; a leg's disruption if someone reports one, including the real arrival time and whether a bag went missing; expenses with their description, amount, currency, the exchange rate frozen at the moment they were added, who paid and how it is split; settlements; pledges; what each person says they have put aside; which checklist rows have been dealt with; the scrapbook — photos and their captions; and a profile photo, if somebody chooses to put one against their own name.
Also: a postcard you ask us to print — which page of the scrapbook it is, the message and the signature you wrote, and the address it is going to. The printer, Stannp, is sent the name, the address, the photograph and the words, because somebody has to put it in the post — see *Where it lives* below. The address is deleted from our server the moment the card is despatched: it belongs to somebody who is not using Mayzee and never agreed to anything, so we keep it only for as long as it takes to put it in the post, and it is never remembered, never suggested and never used for anything else. What survives is the card itself — the photo, the message, the typed and drawn signature, and that you confirmed the people pictured were happy to be — until the trip is deleted or you ask to be erased. Not who it went to.
A postcard code you bought or were given. A code is eight characters and it is not about you: we keep the code itself, what was paid, and — once it is used — which trip and which person used it, so that one code buys one card and cannot buy a second. We are not sent your name or your email address; if you paid, that is between you and Stripe. A code is not tied to you, which is why you can give one away and it still works.
A first class stamp you bought. The pound that upgrades a free postcard from second class to first is the same kind of thing as a code and is kept the same way: a token, what was paid, and — once it is used — which card it was used on, so one pound buys one stamp and cannot buy a second. It is not tied to you and we are not sent your name or your email address; if you paid, that is between you and Stripe. If the trip the card was on is deleted, the link to that card goes and the record that a pound was paid stays, because a deleted holiday is not a refund.
A hoodie you ordered. This is the one thing in the shop that has to come to *you*, so unlike a postcard code it is tied to you and we say so plainly: we keep what you ordered, what it cost, and where it is going, along with the trip it was for. The address is only ever used to send you the parcel. A person looks at every order before anything is printed, the same way they look at a postcard, and they can see the address in order to check it is a real one. If the order is refused the address is deleted the next day; once it has been placed with the printer we keep it for 30 days, in case a parcel goes astray, and then delete it. What stays is what you ordered, the amount paid and the date — the takings have to still add up. The printer is Gelato; a person types the name and address into their system to place the order (*Where it lives*, below). What you paid with is between you and Stripe; we are not sent your card details. The shop's pictures of a trip's hoodie carry the crew's first names, because the print does.
A photo you add in the shop. You can put your own photo on a trip hoodie, tee or tote before the trip has a scrapbook. It is not a page of the scrapbook: nobody else on the trip is shown it, and only you are offered it again. We keep the photo, which trip it is for and that it was you who added it. It is deleted as soon as the order it is on has been sent to the printer, or 30 days after you added it if you never ordered with it, and before that if the trip is deleted or you ask us to erase you. While an order with it is waiting to print, it stays, because that is what is being printed. The person at the desk sees it before approving the order, and the printer gets it as part of the print file.
Your tick before any photo is printed. Before you can order a garment with a photo on it — one you added in the shop or a page of the scrapbook — you tick *Everyone in this photo is OK with it*, and we keep when you ticked it with the order. A scrapbook page stays in the scrapbook after the order; it is not deleted because it was printed.
A face you put in one of our drawings. If you put somebody's face into one of the shop's drawn scenes, the photo is kept the same way as above: it is deleted as soon as the order it is on has been sent to the printer. Before you can order it you tick *I have their OK to use their face*, and we keep when you ticked it with the order, along with which drawing it was and where you placed the face in it. The iPhone app finds the face in the photo on the phone itself; nothing is sent anywhere to do that. The person at the desk and the printer see the face, because it is what is being printed.
Your shop bag. What you add to the shop's bag (which garment, design, colour, size, how many, and whether you ticked the box for a photo) stays on your phone, or in your browser for that trip, until you check out. We are sent it only when you tap Checkout, and then as orders: each line is kept the way *A hoodie you ordered* says, with your tick kept with its own line. Once that checkout is paid, the lines in it leave the bag.
Opening the shop from the app in your browser. When you tap Checkout in the app, it sends us your bag, asks us for a one-time code and opens the payment page with it, so the page knows it is you. The code works once, for one minute, and we keep only a scrambled form of it, which trip and member it was for, when it ran out and whether it was used. Used and run-out codes are deleted every night, and with the trip or when you ask to be erased. Your browser then keeps a cookie saying who you are on this trip's shop for a day; it works only in the shop.
A lift you have asked somebody for. If you ask the person driving to pick you up somewhere, we keep who asked, which journey, the place and the time until they answer — so the request is there next time they open the app. It goes when you are taken off the trip or ask us to erase you, because it is a question rather than a record: *pick me up at Farnborough* means nothing once you are not going.
A trip can have a word on it, and we cannot tell you what it is. The organiser may put an optional password on a trip: without one, anybody who ends up with the link can open the trip and see the photographs in it, and with one they cannot. We do not store the word. What is stored is a PBKDF2 hash of it and a salt unique to that trip, which is a one-way street — there is no way back to the word from what we hold, so nobody here can read it, recover it or tell it to anybody who has lost it. The organiser can change it, and that is the only way back in, which is why there is no email box and no reset link anywhere near it.
Your phone does not keep the word either. It sends it once, gets back a signed pass with an expiry on it, and holds that instead — so the word is not sitting on your device or travelling with every request. The pass is worthless on any other trip and stops working the moment the organiser changes the word.
We count how many wrong words have been tried on a trip, so that a word cannot be found by trying every word, and we count how many requests each minute name a trip code that does not exist. The second is deliberately not counted per person: we could throttle by address and we do not, because we said we would not read it.
We also keep the sentence you agreed to when you posted it, and the moment you agreed. Sending a card confirms two things nobody here can check by looking — that everyone in the picture is happy to be on it, and that nobody in it is under 18 unless you are their parent or have a parent's say-so — so the card carries the exact wording that was on the button and the time it was tapped. It is kept with the card, it is about you rather than about the person receiving it, and it is there so that what you agreed to is a matter of record rather than a screen somebody remembers.
Two things about that changed on 1 September 2026, and both are worth stating plainly.
A card is looked at by a person before it is printed. The postcard is free and it carries our name on the back, and a printed object cannot be recalled from a postbag — so every card waits on a queue that one of us reads, and nothing goes to the printer until somebody approves it. What that person sees is the card: the photograph, the words, which trip it is and which country it is going to. They are not shown the address. A card nobody gets to within a week is let go of and its address deleted, because an address may not sit on our server waiting for us.
We keep one opaque number that identifies your phone, not you. The card is free, one each, and a trip costs one tap to create — so without something stable to count, one person could ask for as many free cards as they could be bothered to make trips for. The number is made up by the app the first time you ask for a card, kept in your phone's keychain, and sent only on that one request. It is never attached to your name, never sent when the app loads a trip, and it answers exactly one question: *has this phone had a free postcard in the last thirty days.* It is stored against the card you asked for and goes when that card's trip is deleted, or when you ask to be erased. On the phone it survives deleting and reinstalling the app — on purpose, or deleting the app would be a way to a second free card.
Also: a report, if somebody reports a scrapbook page — which page, who reported it, who posted it and the reason they typed — and a block, if somebody blocks another person on a trip: who blocked whom. A report takes the page down before anybody looks at it, and the record is kept because a complaint has to outlive the thing complained about. Erasing yourself unhooks your id from both.
Also: the answer to each write, for a while — when a phone sends a write with no signal and the reply is lost, it sends the same write again, so the server keeps the first answer under the request's own key and hands it back instead of writing a second row. The copy is the reply as sent (ids, never names or addresses), it belongs to the trip and it goes when the trip does.
Also: anything somebody adds to the packing list, and who added it — the list itself is worked out from the forecast and the plan rather than stored, but a thing you type onto it is yours and is kept. And: where the group is staying — the name, the address, the check-in and check-out times, and a free-text note for anything the group needs to know about the place. A trip can have several, and which of them each person is sleeping in: that is a list of member ids against an accommodation, put there by you or by anybody else on the trip, and it is what lets the app take the right person back to the right door. It goes when you ask to be erased, and when the trip is deleted. Also: places somebody saved to the trip's map, with their coordinates and whatever they were called; and booking references, for a stay, a travel leg, or something on the plan.
An append-only log of what happened on a trip: the kind of thing (a vote was cast, a destination was proposed, an RSVP changed), which member id did it, the destination name if it is relevant, and a small structured payload. Alongside it, a counter of which checklist rows were shown, per trip per day.
This is how we work out which of the jobs Mayzee offers to do are ones people actually want done, rather than the ones we found interesting to build — including which rows people go out of their way to make go away, which is the more useful half. The report that reads it is aggregate only: rule ids and counts, no trip codes, no member ids, no destinations, no names. It is not public — it used to be reachable by anyone who guessed the path, and is now behind a secret only we hold.
The log keeps no time limit of its own: it goes when the trip is deleted. Erasing yourself takes your member id off every line of it, including the ones that recorded the request address.
What people use, across the app and the website (from 7 October 2026). Which screens are opened, which actions are taken — named by the kind of thing (*"added a plan item"*), never its contents — the app's version, and the city the trip is going to. Each phone or browser is counted by a random number made for this alone: not your member id, not your name, not your trip, and nothing you typed. It goes to our own database and nowhere else, is read only as totals, and is deleted after thirteen months. *Help improve the app* on the You screen switches it off, and switching it off forgets the random number too.
The iOS app. In the app's own preferences: the codes and names of the last ten trips you opened, with when you opened each, and your member id for each trip. In the app's Application Support folder: the whole trip payload as a file, so the app still answers on a plane; a queue of writes waiting for signal; the shop bag for each trip until you check out; and a timestamp of the last successful refresh. Deleting the app deletes all of it.
In the iPhone's keychain, and only there: your passport's two dates and which passport you travel on, so a second trip does not ask you to type them again; and your name, sort code and account number, if you chose to add them, so they can be attached to a settle-up message you send yourself. None of that reaches us. There is no account in this product, so there is nowhere on our side for it to live, and that is the reason rather than the obstacle: what we never receive is what we cannot lose. It is stored so that it does not follow a backup onto a second phone. "Forget it" on the You screen removes it at once, and because the iPhone's keychain outlives an app that is deleted, the app also forgets it by itself on the first launch after a reinstall.
Also on the phone, in ordinary app preferences: which things you have ticked off a packing list. Nobody else is told, because nothing about the holiday changes because you found your charger.
Also in the keychain: what you eat, if you said, beside your passport dates; and the references of postcard packs you bought, which iCloud keeps in step across your own devices. In the app's preferences: a signed token per trip that proves to our server you are the person you joined as; the pass for a trip that has a code word; a postcard you are halfway through writing, for an hour; and, unless you switched *Help improve the app* off, a random number made for counting what gets used — deleted with the app.
The website. In localStorage, per trip: your member id, the signed token, the pass for a trip that has a code word, the packing items you have ticked, and the shop bag until you check out; plus which look you picked and, unless you switched it off, the random number for counting what gets used. Five cookies, none of them a tracker:
mzp_<trip>, a copy of the pass for a trip that has a code word, sent only when your browser loads that trip's pictures (a year);mz_shop, the pass for a trip's shop when the trip has a code word (a year);mz_buyer_<trip>, your member id and signed token for that trip's shop, so the order page knows it is you and can show your own photos. Sent only to the shop's pages. It lasts a day, and *Forget this trip on this computer* removes it;mz_tester, which lets the people testing Mayzee past the *coming soon* page before launch. It holds nothing about you (a year);mz_desk, for the people who approve postcards (twelve hours).Not only in the UK. Some of the companies below are based outside the UK and the EU — Cloudflare, Stripe, Anthropic and Apple are American — so what you put into a trip may be stored or processed outside the UK and the EU.
Cloudflare runs everything. The Worker, the database, the photo bucket and the CDN are all theirs, and they process it on our instructions. As part of delivering a request they see your IP address, as any host does. Cloudflare's request log is on: it records each request's address on our server — which contains a trip's share code and sometimes a member id — its status, and Cloudflare's own request details; our own error lines add the request and its error. When the app checks the spelling of a place you typed, that place is in the address too. How long Cloudflare keeps it on our plan we have not verified; this page will say when we have. Cloudflare's web analytics is switched off.
Anthropic sees a small, deliberate slice, and only on a trip that said yes to suggestions. When someone taps "Suggest something" on a day, what is sent is: the destination, the group size as a number, which day is being filled, the titles (and times) of things already on the plan, and — if anyone on the trip has shared a diet — which diets the group has, with nobody's name against them (*"someone keeps kosher"*), so the ideas suit the table; and the trip's answers to *What's your crew into?* and its budget band, if the organiser gave them. Plan titles are typed by people and can contain anything, names included. No member ids, no money, no passport dates, no photos. Two smaller calls run without a tap and carry a place name and nothing else: when a group decides on a place our own tables do not know, we ask which of our existing drawings fits it; and after a suggestion we warm a pool of ideas for that place, so the next group going there does not pay for the same three; and once per place, it reads that place's Wikipedia article and picks a few surprising facts for *Explore the culture*. Anthropic is in the United States, so that is an international transfer. Nothing about a person is in any of it.
Wikipedia gets the destination's name once per place, from our server, to read its article for *Strange but true*. Nothing about anyone is sent.
Frankfurter gets a currency code once a day, from a scheduled job, to fetch European Central Bank exchange rates. Nothing about anyone is sent.
Open-Meteo gets the destination's coordinates, rounded, from a scheduled job, to fetch the forecast. Nothing about anyone is sent.
OpenStreetMap, through the Overpass API, gets the destination's coordinates once, to build the list of public hospitals on the help screen. Nothing about anyone is sent.
Stannp, the printer, is sent a postcard: the recipient's name and postal address, the photograph and the words on the back. They print and post it on our instructions and for nothing else, which makes them a processor — and they are the one third party that receives something about a person who is not using Mayzee. Once a card is posted, what Stannp keep of the address is governed by their own privacy policy, which we have not verified; this page will say when we have.
Apple distributes the app and, if you have opted into it on your device, receives crash reports directly from iOS. We have no crash-reporting or analytics SDK, so we do not see those unless Apple shows them to us in aggregate. The app also uses Apple's map search on your phone: to find where a plan item is, and to suggest addresses as you type where you're staying — so what you type there, and the address, go to Apple, with your phone's IP address.
Stripe takes payment in the shop. What you bought and our order reference go to them; they collect your card, your email and, for a hoodie, the delivery address, under their own privacy policy. Gelato prints hoodies: a person here places each order by hand, so they get the name and delivery address, and the print file, which carries the trip's name and the crew's first names, or the photo you chose: a scrapbook page, your own shop photo, or a face in one of our drawings. postcodes.io is asked whether a postcard's postcode is real, and is sent that postcode alone.
The map in the app draws its lettering from files on our own server since 7 October 2026. App builds before 17 fetched them from GitHub, which saw the phone's IP address.
Fonts. The landing page, these pages and the web app serve the fonts themselves; no page loads anything from Google.
Nobody else. No advertisers, no data brokers, no measurement partners, no "analytics-as-a-service". If that ever changes, this page changes first.
Most photos go into the scrapbook, which is the whole point of them: a page the group buys at the end. The other kind is a profile photo — one picture you can put against your own name so the group sees a face instead of a letter. Both are stored in our R2 bucket, keyed by trip, and served back through the app rather than from a public bucket URL — so a trip's photos sit behind its share code, not behind a guessable address.
Nothing about where you were leaves your phone. A photo you *take* inside the app is re-encoded on the way out, which drops the camera metadata as a side effect. A photo you *pick from your library* arrives as the original file, which on an iPhone usually still carries the GPS coordinates and the time your phone recorded when it was taken — so those are stripped, deliberately, before it is uploaded. Location, the device's serial number and the IPTC block all go. Orientation and the colour profile stay, because a photo stripped of those draws sideways and grey.
We have no feature that wants to know where a photo was taken, so there is no version of this where we keep it.
A photo you add in the shop for a garment is the third kind: yours alone, stripped the same way, and deleted on its own schedule (*A photo you add in the shop*, above).
A profile photo is also shrunk to 512 pixels on your phone before it is sent. It is drawn next to a name at about the size of a thumbnail, and a full-resolution one would be a larger picture of your face sitting on our disk for no reason at all.
A profile photo is not proof of who anybody is. There are no accounts here — see the next section — so a photo next to a name is exactly as strong a claim as the name itself, which is to say: it is what somebody with the link said.
There are no permissions in Mayzee, by design. Anyone holding a trip's link can see and edit that trip. It is friends, not a company, and a group holiday where three people cannot add a restaurant is worse than one where somebody moves the dinner.
That means the share code *is* the security. It is seven characters from a 31-character alphabet — about 34 bits, which is fine against someone guessing and is not a bank vault. Treat a trip link like a shared Google Doc link: everyone you send it to is in, and so is anyone they forward it to.
Two things follow that are worth saying out loud rather than burying:
/demo on the website makes a fresh copy of an example trip for whoever opened it, remembers its code in that browser, and sweeps it after seven days. While it lasts it is a real trip on our server — anything you type into it is stored like anything else — and it is marked as a demo, so it is left out of the usage counting above.
When you start a trip we ask, once, whether you would like to be told when the iPhone app is out. The trip is already made by the time we ask, so saying no costs you nothing — and if you joined a trip from somebody else's link, we never ask you at all. If you tick the box and give us an address, this is the whole of what happens to it.
We store your email address, the date, and which trip you were starting. No name and no location. We keep the trip's internal id — not its share link — so the one email we send can say which holiday it is about instead of being a circular. That id opens nothing on its own.
We use it for one thing: to tell you the iPhone app is out. That is the purpose you consented to and it is the only purpose we have. We do not use it to send anything else, and it does not give you an account or change anything about the trip.
If the trip is deleted, we forget which trip it was and keep the address. You asked to hear about an app, not about a holiday, so binning the holiday is not a request to be unsubscribed — the link goes, the subscription stays until you end it.
We never sell it, swap it or share it with anybody. Not with partners, not with advertisers, not with another company in exchange for theirs. If we ever wanted to do something else with an address we would have to ask you again, separately, before doing it — consent given for one thing cannot be reused for another, and we would not want to anyway.
The lawful basis is your consent, given by ticking a box that is never pre-ticked. You can withdraw it whenever you like: every email we send has an unsubscribe link in it, and you can email us to be removed at any time without waiting for one. Being removed means the row is deleted, not flagged.
We keep it until the app launches and we have told you, or until you ask us to remove it — whichever comes first. We are not building a long-term marketing list out of it.
Honestly: little is deleted on a schedule today. A trip and its photos stay until somebody asks us to remove them. What does go by itself: the notes about where you stayed, a day after check-out; a postcard nobody has reviewed inside a week, with its address; a photo you added in the shop, or a face in one of our drawings, as soon as its order goes to the printer, or 30 days after you added it if it was never ordered; and a demo trip, seven days after it was made. Nothing else. Taking a person off a trip yourself — the "remove" in the Crew tab — marks them as removed and hides them from the app, but keeps their row and their expense history, because a hard delete there would silently rewrite what everyone else owes. That is not the same thing as asking us to erase you, which is below and does far more.
The first of those, and it is deliberate: the notes about where you stayed. There is one notes box on a place you are staying, and it is yours to use however you like — how you get in, the wifi, whether the gate needs locking at night. We never ask you for a door code, and we delete whatever is in that box one day after your check-out date. Not the name of the place, not the address and not the times, which are yours to look back on. Just the notes, because they are worth nothing to you afterwards and we would rather not be holding them. They go from what the app can read and from our database, and neither of those depends on the other having worked.
And one thing goes the other way, deliberately: a booking reference. A door code is worthless to you the moment you check out and remains a risk for as long as we hold it, which is why the notes are swept. A reference is the opposite on both counts. If a flight is delayed you have six years in England and Wales to claim, and the airline will ask for the reference — so a sweep would take it away at exactly the moment it becomes the thing you need. It stays until the trip is deleted or you ask us to erase you.
That is not where the rest of this should end up, and the retention period for everything else is a decision that has not been made yet rather than one we are hiding. Until it is:
> Status, 23 Aug 2026. There is still no automatic deletion and no self-serve "delete > this trip" button on either client; both are on the list. What changed today is that the > two things this page promises now exist in the code and are tested: a request to delete a > trip, and a request to erase one person, described exactly below. Before that they were a > promise with nothing behind them.
Everything, everywhere, and it does not come back. Every row in every table that belongs to a trip — the trip itself, everyone on it, the places proposed, every vote, objection, delegation and abstention, the plan and who said they were in for each thing, travel legs and claimed seats, expenses and their splits, settlements, pledges, what people said they had saved, what was ticked off the list, the scrapbook, where the group stayed, the packing list, any postcard, reports and blocks, and the usage log — plus every photo, deleted out of the bucket rather than just unlinked from it.
A code you bought is not deleted with the trip, and that is deliberate. What goes is the link: which trip and which person used it. The code stays, and a used one stays used — deleting your trip does not take back a card that has already been printed and posted, and it does not destroy the other codes you are still holding.
It is deleted table by table by name rather than left to the database to cascade, and the same list is counted again afterwards so the answer says what is *left* rather than what we meant to do. The only things not touched are the shared caches — the day's exchange rates, the weather at a rounded set of coordinates, a place's pool of ideas and which drawing it gets — which hold nothing of anyone's and are shared between trips.
The identity goes and the arithmetic stays.
Gone. The name they typed, replaced with "Someone". Their passport dates and their insurance answer. Every photo they put in the scrapbook, out of the bucket and out of the database — a picture of a person is the most identifying thing this product holds, and the caption under it is their words — and their profile photo with them, which is the picture they chose to be recognised by, and any photo they added in the shop for a garment. Their travel: flight numbers, times, airports, the pickup point outside their house, and any seat anyone had claimed on it. Their votes, objections, delegations — including a delegation somebody made *to* them — and abstentions. Their answers about which dates they could make, which is a fact about them and nothing else depends on it — unlike the ledger, where the arithmetic outlives the identity. What they said they were in for on the plan, what they had ticked off, and what they said they had put aside. A postcard they asked for that has not yet been printed is cancelled and its address deleted. And their id is unhooked from every line of the usage log, and from any report or block, so what is left of it records that a thing happened and not who did it. One thing is left pointing at the emptied row: an item they added to the packing list still carries their id as the person who added it, which after erasure identifies nobody.
Kept, and here is why. Expenses they paid, the shares they owe, settlements they were part of, and their pledge. Those are not a record about a person; they are the record of a transaction *between* people, and everyone else on that trip is entitled to it — it is what they need to work out who owes what, and to argue about it afterwards. Kept with them is the row itself, emptied of everything above, because a share pointing at an id that no longer exists is a hole in the ledger rather than a deletion.
What is left is a random id, an amount and a rounding rule. Nothing in it says who they were, and there is nothing on our side that can turn it back into a person. They are also marked as removed, so they are out of the crew list and out of everything the app shows while still being counted in the settle-up.
If you would rather have the ledger gone too, that is the whole-trip deletion above, and it needs the rest of the trip to be content to lose theirs.
Neither is something a trip link can fire. Both are held behind a secret that lives only on the server and with whoever answers the address at the top of this page — no phone, no browser and no share link carries it, which is deliberate: the share code is meant to be a weak lock, forwarded around a group chat, and that is exactly right for adding a restaurant and exactly wrong for destroying a whole group's holiday. On top of that, each request has to name what it is aimed at — the trip's own code, or the person's own id — so a half-remembered command cannot land on the wrong trip.
Under UK and EU data protection law you can ask us to give you a copy of what we hold about you, correct it, delete it, hand it over in a portable format, or stop using it. You can also complain to the Information Commissioner's Office at ico.org.uk if you think we have got this wrong, though we would rather you told us first.
How to ask. Email info@mayzee.app with the trip's link and which name on it is yours.
And here is the awkward part, said plainly. Because there are no accounts, we cannot strongly verify that you are who you say you are. Anyone holding a trip link can ask about that trip. That is the direct cost of the decision that makes the rest of the product work, and pretending otherwise would be worse than admitting it. Where a request would affect other people on the trip — deleting a shared expense history, for instance — we will say so before doing it.
Our lawful basis for holding all of this is legitimate interests: you gave a group of friends your name and your flight time so the group could organise a holiday, and that is what we do with it. The usage counting described above is also legitimate interests, and it is aggregate. If we ever want to do something with destination data beyond that — and we might, because knowing thirty groups are going to Krakow in March is genuinely useful to a hotel there — we will ask the trip for consent, in plain words, once, and take no for an answer.
Mayzee is not aimed at children and is not designed for them. We do not knowingly collect anything from anyone under 13. If a child's name is on a trip because a family put it there, it is a first name and an RSVP, and you can ask us to remove it.
Everything travels over HTTPS. Photos are served through the Worker rather than from a public bucket. The database is Cloudflare D1, reachable only by our Worker.
We are a small operation and we are not going to claim a certification we do not have. What we can tell you is what is *not* there to lose: no passwords, no email addresses, no payment card details, no passport numbers, no IP addresses.
Mayzee does not move money and does not hold it. Every number in the Money tab is a record of a promise: who paid for the boat, what everyone owes, what each person says they have put aside. Settling up happens between you, in whatever app you already use. We are not a payment service and we do not want to be one, because holding other people's money is regulated and a scoreboard is not.
The date at the top moves and the change is described here. If a change means we start collecting something new, or sharing something with someone new, it will be at the top of this page rather than in the middle of a paragraph.