← The Flight Crew App

Privacy

Written to be checked, not to be survived. It says what leaves your phone, when, and to whom, including the parts that are inconvenient to admit.

THE SHORT VERSION

Your roster, your flight history and your pay figures live on your phone, and the app is whole without an account. Three things leave the phone, and only when you ask for them: a photo you ask it to read, your roster or the alternates page of a flight plan, which passes through a server of ours and is read by Google's Gemini; the aerodrome codes for a briefing, which go to our own weather service; and, if you switch it on, an encrypted backup, which we store sealed. Your pay is never in it: the salary tables and the figures in your pay profile are stripped out before anything is sent, so a backup of yours would not say what you earn even if it were opened. We do not read your backup. There is a way back in for the day you lose every device and every key at once, because a logbook can be the record of a career and there is no rebuilding one from memory: you ask for it, it waits a day, it tells you while it waits so that you can stop it, and it leaves a record we cannot erase. It is set out in full below, in the detail it deserves. Separately, if you join the early access list, that list holds the email, operator and seat you typed into it.

WHO WE ARE

The Flight Crew App is in private beta. One address answers for everything on this page, including a request to delete what we hold, which we answer within a month: hello@theflightcrewapp.com

THE EARLY ACCESS LIST

The waiting list has its own page: what we keep about the people who ask for early access, for how long, and who sees it. It changes at marketing's pace; this page changes at the product's. The legal basis there is your consent, given by sending the form and withdrawable at any time without giving a reason.

THE APP ITSELF

The app needs no account. It stores what it needs in the browser's own storage on your device: your roster, the airports you have taught it, your pay profile, and any salary tables you paste in. None of that is uploaded to us unless you switch on the encrypted backup described below, and a plain backup file exists only if you export one yourself.

Reading a photo sends it to Google, and it goes through us on the way. When you ask the app to read a photo, the image leaves your phone, arrives at a server of ours, and is read by Google's Gemini. That is a third party handling a document with your name and your duties on it, and it is the single most important sentence on this page. It happens only when you choose to read a photo, and the app tells you so at the moment you do it. If you would rather it never happened, add your duties by hand. Everything else in the app works the same way.

Why it goes through us. The key that pays Google is ours, and on your phone anyone could take it and spend it, so it stays on our server and the photo comes to it. The cost of that is worth saying plainly: while the reading happens, the photo is with us and it is not sealed. It is held in memory, never written to disk, and discarded as the reading starts. A photo nobody collects is swept within 75 minutes at the very worst.

What outlives the photo is the reading, not the image. The text that came back waits 30 minutes, at the outside 90, so a phone put back in a pocket can still collect what it paid for. For rosters only, we keep a fingerprint your phone computed for an hour, at the outside two, so the same photo is not charged twice. It is the fingerprint we store, never the photo. A flight plan page has neither.

What Google may do with it. We pay for the reading, and on the paid terms Google does not use what is sent to train its models. Logging is switched off in our project, and we do not hand anything over as a dataset. What Google keeps for its own abuse checks is theirs to say and not ours to promise, so this page puts no number on it.

Fetching weather tells our service which aerodromes you are briefing. METAR, TAF and NOTAMs are requested through a service of ours, which sees the four-letter codes and nothing else: no name, no roster, no times. If you prefer, paste the bulletins in by hand and nothing is requested at all.

Your pay never leaves this phone. Salary tables are typed or pasted by you and are not built into the app, and neither they nor the figures in your pay profile are ever sent to us. They are not sealed and uploaded: they are removed by name from the backup before it is sealed, so that a field added later cannot travel by accident. The practical consequence is the part worth having: what we store is your roster and your logbook, and a backup of yours would not say what you earn even if somebody opened it. The pay-package reader keeps the same promise from the other side: your package PDF is read on this phone and never leaves it. It is not uploaded, and the file itself is not kept.

The app is behind a sign-in gate during the private beta, and that gate is the app's own screen: you type your email address and we send you a six-digit code. It is our own server that receives the address, not a third party standing in front of the app. What we then hold, and for how long, is the section below.

YOUR ACCOUNT AND YOUR BACKUP

Both are optional, and the app is whole without them. Every hour of work already on your phone keeps working with no account at all, in a hangar with no signal. The backup sits on top of what is local; it is never a gate in front of it.

The account. Signing in uses your personal email address and a code we send you, so we hold that address, when you joined, when you last signed in, whether a subscription is live, and a reference from the payment provider. We never see a card number. Each device gets a random identifier with no name and no model: "Juan's iPhone" does not exist on our server.

The backup is encrypted on your phone before it leaves it. The key is made on your device and stays there, and in the ordinary running of this service we hold nothing that opens it. What we store are sealed blocks. This page used to say we could not read them, and until recently that was true. It is not true any more, and the rest of this section is why.

There is a way back in, we are the ones who hold it, and that is why it is set out here in full. Every account has a recovery envelope: a copy of your key, sealed against a private key of ours that lives inside a hardware security module in the European Union, that no server of ours can read, and that one narrow function is allowed to use. It is there for the day you lose the phone, the passkey and the code at once, so that losing them does not also cost you your logbook. Holding it means we can open a backup, and we would rather you knew exactly what has to happen first. It is deliberately slow and loud:

One account at a time. Never in bulk. And it is part of every account: it cannot be switched off, because an account without it is an account we could lock you out of for ever.

What we will not claim. Not that it is impossible for us to open your backup: it is not. Not that no such key exists: it does. The honest sentence is that we cannot open it quietly. Not without you being told, not without a day passing, and not without leaving a mark we cannot rub out. What the encryption still buys is real and worth having: a stolen database gives up not one flight, nobody here can browse anybody's logbook out of curiosity, and there is no way to do this to many people at once.

And a court order. An order that reached us could reach that key. We would require it to name the account, we would tell you unless the order forbade it, and it would go into the same record as any other recovery. We spell this out because this page used to say that an order over our storage returns blocks of no use to anyone. That stopped being true on the day that key came into existence, and a promise that has quietly expired is worse than one that was never made.

What the server does know, written out because a page that tells only the comfortable half protects nobody: who you are, whether you pay, how many records you hold of each kind, how big they are, when you sync and from how many devices. It also keeps the accounting of every photo you have had read: which month the photo covered, which model read it, how long it took, whether it worked, and what it cost in tokens. An allowance has to be counted somewhere and the phone is not somewhere we can trust to count it. That accounting holds no content at all: not an aerodrome, not a line of the text, not the photo. And it has no expiry date. It lives as long as your account does and goes when your account goes. It is kept so that a bill can be explained, and explaining last spring's bill means still having last spring.

What it does not know is what any of them say. Your operator and your nationality are an example worth giving rather than leaving to trust: they are inside the backup, sealed with everything else, so they do leave your phone, shut exactly as tightly as the rest of it and on the same terms set out above. Sealed is not the same as absent, and this page says which of the two it means.

Three of those deserve naming rather than burying. How many times a record has been edited is visible to us: that one duty was corrected three times sits in the clear, and that is exactly the sort of thing an employer would want to know. The moment an upload arrives is, in practice, the date of the record, because the app is used at the end of a duty, so "we do not know when you touched each flight" is a weaker promise than it sounds. And the rhythm: an account that syncs often belongs to somebody who flies often. A short list and a short retention limit all three; nothing removes them.

Deleting is real deleting. One record, a whole collection, or the entire account: the sealed blocks go at once. Our own operational copies rotate out within 30 days, so a deletion is total and irreversible within 35 days at the most, and the confirmation says so in those words. One thing is deliberately write-once, and it is named rather than buried: the record of recoveries, which says who asked to open which account, from which device, and when. That is kept for five years, and for the first of them not even we can alter it. It holds account identifiers, devices and times; it never holds anything out of your logbook. We keep it because it is the only proof of what was and was not opened, which protects you before it protects us, and the law allows exactly that: keeping what is needed to establish or defend a legal claim. Nothing else here is append-only, because a technical impossibility is no excuse for failing to delete. Nothing here deletes itself on a timer, and that is deliberate. A logbook can be the record of a career, and a subscription that lapses is not somebody saying they want to lose it. Your sealed blocks are kept for as long as your account exists, whether you are paying or not, and they go when you ask or when you close the account. If we ever change that, this page says so before it happens and not after.

Where it lives, and who else is in the path. The server is in the European Union. Cloudflare stands in front of it, as it already does for the whole site, and it is a US company. For your backup this costs nothing: the blocks are sealed on your phone, so they mean nothing to anyone in the path, and what passes are connections and addresses. For a photo you send to be read it costs more, and it is the one thing on this page we cannot seal away: a photo is not encrypted by your phone, so Cloudflare handles it in the clear on its way to us. It is the only thing you send us of which that is true. Amazon Web Services holds the recovery key, in Frankfurt, in an account kept apart from the one that stores your data, and it also runs the clock and sends us the alert that go with a recovery. That is the most important name on this list, so it is named: it is the one company whose part in this could open anything. Like Cloudflare it is American, with European regions. The sign-in codes we email you go through a mail provider inside the EU, and that provider keeps its own record of which address a code went to and when, the same way the one behind the waiting list does. When there is a subscription, a merchant of record handles the payment and the tax and the card details are theirs, never ours. Everyone in that list works on our instruction, and none of them may use anything of yours for purposes of their own.

The access logs keep a truncated IP address, the time and which endpoint was called, for 30 days, and then delete themselves. Your account identifier is not stored beside your IP address except where security requires it.

OTHER PEOPLE'S NAMES, INSIDE YOUR LOGBOOK

A flight log names the people you flew with. Those names are sealed with everything else, we have never read one, and they are used for nothing at all. They sit in your backup because they are part of the record you wrote.

We are telling you, and them, here, because we cannot tell them one by one. The law says that when we hold someone's data without having got it from them, we should tell them. We cannot: we do not know who they are, and finding out would mean opening exactly what this page says we do not open. The law's answer for that case is to make the information public instead, and this paragraph is us doing it.

So if you are named in someone's logbook and you write to us, we will not be able to find you, and we will not open anybody's backup to look. Doing so would be a greater intrusion than the one it was meant to answer, and it would break the only promise that makes any of this defensible. What we can tell you is that nothing of yours is readable by us, that it is never used, never shared and never analysed, and that it goes when the person whose logbook it is deletes theirs.

Our ground for holding it is our legitimate interest in giving a crew member a backup of their own professional record, one their licence can depend on. We weighed that against the interests of the people named in it: what is held is minimal and professional, it is encrypted, it is never read or used, and the only circumstance in which it could ever be seen is a recovery that its own owner asked for, waited a day for, and that was written down. If you think that balance is wrong in your case, write to us and say so. That is a right you have, and we will answer.

YOUR RIGHTS

Under the GDPR you can ask us for a copy of what we hold about you, ask us to correct it, ask us to delete it, or object to our using it. Write to hello@theflightcrewapp.com and we will answer. You also have the right to complain to your data protection authority; in Spain that is the AEPD.

Most of what the app knows about you is not ours to hand over or delete, because it is on your phone: clearing the app's storage, or deleting the app, removes it. That stops being the whole answer the moment you switch the backup on. The account and the sealed blocks are ours to hold, so they are ours to delete, and deleting the app from a phone does not touch them. Ask us, at the address above or from inside the app, and the paragraph on deleting above is what happens.

WHAT THIS PAGE DOES NOT DO

No advertising, no tracking pixels, no analytics that follow you elsewhere, and no cookies at all. An account keeps you signed in with a token the app holds on your phone rather than a cookie, alongside the random device identifier described above, and both are gone the moment you sign out.

WHEN THIS CHANGES

If the app starts sending something new anywhere, this page changes on the same day the feature does, and the change is named rather than folded into a new version number.

© 2026 THE FLIGHT CREW APP