Last updated 30 August 2026.
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. Jonny Anderson, trading as Mayzee. [POSTAL ADDRESS — STILL TO ADD]. How to reach us. info@mayzee.app.
Mayzee is a shared workspace for organising a group holiday. 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 seven 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 SDK, no analytics SDK, and no tracker of any kind in the app or on the website.
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 Kraków 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 and one Cloudflare R2 bucket, both named mayzee.
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 ("six 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".
Destinations proposed and the notes on them; votes, objections, delegations and abstentions; 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 address is deleted 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 that a card was sent, not who to.
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.
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; 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 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; 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, and deleting the app deletes it.
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.
The website. One localStorage entry per trip, holding your member id, and the packing items you have ticked. No cookies. We set no cookies at all.
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. Our own application log holds one line: an error message if the suggestions feature fails, with no personal data in it.
Anthropic sees a small, deliberate slice, and only when someone taps "fill this day". What is sent is: the trip name, the destination, the group size as a number, which day is being filled, and the titles of things already on the itinerary. No names, no member ids, no money, no passport dates, no photos. Anthropic is in the United States, so that is an international transfer. It does not happen unless someone presses the button.
Frankfurter gets a currency code once a day, from a scheduled job, to fetch European Central Bank exchange rates. Nothing about anyone is sent.
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 of our own, so we do not see those unless Apple shows them to us in aggregate.
Google Fonts is the one third party on the *website* we would rather not have. The two typefaces are loaded from fonts.googleapis.com, which means your browser's IP address and user agent reach Google when the page loads. The iOS app does not do this. We intend to self-host the fonts and remove it.
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 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:
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: today, nothing is deleted on a schedule. A trip and its photos stay until somebody asks us to remove them. 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.
One exception, 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 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 one of the twenty tables that holds anything belonging to that 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, and the usage log — plus every photo, deleted out of the bucket rather than just unlinked from it.
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 two shared caches — the day's exchange rates and the weather at a rounded set of coordinates — which are public facts with nothing of anyone's in them, 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. 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. What they said they were in for on the plan, what they had ticked off, and what they said they had put aside. And their id is unhooked from every line of the usage log, so what is left of it records that a thing happened and not who did it.
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 seven people'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 Kraków 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.