Privacy Policy
About this policy
This is Flare's Privacy Policy. It explains what the app collects, why, who else sees or handles it, how long it is kept, and what you can do about it — and, separately, what our website collects if you ask to be told when Flare opens to the public (see the launch-email section below).
It is written directly from the product's own code and database schema, not from a template — every statement below describes what the app actually does, so that what you read here is what actually happens when you use Flare. Where a control is still being built or a schedule is not yet automated, that is stated plainly rather than smoothed over, because a policy that overstates what is enforced is worse than one that is exact about what is not.
Who controls your data
FLARE DATING LIMITED, a company incorporated in Nigeria, is the data controller. The applicable law is the Nigeria Data Protection Act 2023, regulated by the Nigeria Data Protection Commission.
What the app collects
- Your email address, used to sign you in. A one-way scrambled form of it (a SHA-256 hash of your address, lowercased and trimmed) is also stored separately, to count sign-in code requests and stop the login being abused. The address itself is not stored in that table.
We are not going to claim that hash is irreversible, because for an email address it effectively is not. An earlier version of this page said it could not be turned back into your address by us or anyone else. That was wrong, and it is the kind of wrong worth correcting rather than quietly softening: the hash has no secret ingredient, so anyone holding it who already suspects your address can confirm the match by hashing their guess — and there are only so many plausible email addresses. So treat it as a stable identifier that stands in for your address, not as a secret. What it genuinely does is avoid keeping a second readable copy of your email, and it contains no name, no content and nothing else about you.
- Display name, date of birth, gender, an optional bio, the city you enter, and an optional country you select.
- Your precise location, as coordinates. This is used to show how far away other people are.
- Up to six photos.
- Your answers to profile prompts.
- The messages you send and receive once you have matched with someone, and the time each one was sent.
- If you use Share My Date: the venue you type, and — only if you choose to add one — your own phone number. See "Sharing a date with someone you trust" below, because that is the one part of this app that puts anything on a page someone without a Flare account can open.
- If you complete identity verification: the type of ID used, a masked reference to it, the provider's decision, the time you gave consent, and a reference number issued by the verification provider so we can trace the check with them if it is ever disputed. That reference contains no ID number.
The app never stores a raw NIN, BVN or driver's-licence number. Only a masked reference and the decision. This is enforced by the database itself, not merely intended.
What other people can see
Verified users can see your profile. That means your display name, your age, your gender, your bio, the city you entered, an approximate distance from them, and your photos and prompt answers — which are what a profile is for.
Two conditions apply, and they are enforced in different places — worth separating, because one is a guarantee and the other is how we build your feed:
- Only verified users can browse, and only verified users are shown. Enforced by the database. If you have not completed identity verification you cannot see anyone, and nobody can see you. One narrow exception, and we would rather point at it here than let you find it later: if you match with someone, either of you can share the other's first name and a venue with a trusted contact — on a page that person, or anyone they forward the link to, opens without a Flare account. No photo, no profile, no location. See "Sharing a date with someone you trust" below, which describes it in full.
- Preferences are matched in both directions. Gender, age range and distance — you are shown to someone only if their stated preferences fit you and yours fit them. Applied when we build your feed, not enforced by the database. That is a weaker guarantee, and we would rather say so than round it up.
Two things they will not see, enforced by the database rather than by the interface:
- Your coordinates. Distance is calculated from a rounded-off version of your location on roughly a 1 km grid, and only a band ("under 5 km", and so on) is ever shown. Your actual position is never exposed to another user.
- Your date of birth or email address. The age shown is calculated as of the first of the current month, so it does not reveal your birthday.
Be aware that the city is what you typed, and it is shown to other users — so it is as precise as you choose to make it.
Likes, matches and the things you tap
When you like someone — a whole profile, or one photo, or one prompt answer — that like is stored, along with any comment you write on it. The person you liked can see that like and that comment before you are matched: that is how the product is meant to work, and it is worth knowing before you write something you would only say to a match.
Passing on someone is stored too, so we can stop showing you the same profile. A pass can be undone; a like cannot. Once you have liked someone there is no way to take it back from inside the app — deleting your account is the only way to remove a like or its comment (apart from an investigation, described under "Blocking and reporting", in which we may remove a comment ourselves). We would rather you knew that before you tapped.
When you and someone else like each other, your comment becomes the first message of the conversation. It is copied into the chat, attributed to whoever wrote it, and dated when the like was written — so the conversation can legitimately open with a message older than the match itself. If you both commented, both comments are there, in the order they were written.
When either of you deletes their account, all of it goes — the like, the comment, the match and the whole conversation, message text included, from both sides — except anything moved to restricted storage during an investigation (see "Blocking and reporting"). So a match or a chat can disappear because the other person left, not because they blocked you.
Your messages
Once you match, you can send each other text messages. Three things about them we would rather you knew up front than discovered later.
They are stored readably in our database, and they are not end-to-end encrypted. That means we are technically able to read them, and anyone with access to the production database could. We do not read them as a matter of course, but a dating app should say this plainly rather than let you assume otherwise.
A message cannot be deleted or edited from inside the app, and support cannot remove one at your request either. The only time we remove a message ourselves is during an investigation, described under "Blocking and reporting". There is no unsend. The reason is the same as for likes: half-built deletion would leave the two of you looking at conversations that disagree, and a message you sent is also part of the other person's record of what happened. The only way to remove your messages is to delete your account (apart from the investigation case above).
The other person keeps seeing the conversation unless you block them or one of you deletes their account. Blocking hides it from both of you — see below. Short of that, there is no way to withdraw a conversation from someone.
We do not have read receipts, and this is enforced rather than merely absent: whether you have opened a conversation is recorded so we can show you an unread badge, and the other person is never told whether you have read theirs — not in the app, and not in a copy of their data. Your own record of what you have opened does appear in a copy of your data, because it is information about you.
Emails we send you about activity
When you get a new match, message or like, we email you about it. Four things worth knowing, because each is a decision we made rather than a default we inherited.
The email contains no names and no message text. It says "2 new matches, 5 new messages" and nothing else — no photos, no who, no what was said. The subject line is always the same words, "You have new activity on Flare", with no counts in it either. That is deliberate: a subject appears on a lock screen before anyone unlocks anything, and an inbox may be shared, borrowed or synced to a work laptop. To see who or what, you open the app.
We batch them. At most one email an hour, at most three a day, and none between 10pm and 7am — they wait until the morning instead. If you have already opened a conversation before the email would have gone out, we do not send it.
There is no tracking of any kind in them — no tracking pixel, no click tracking, no images loaded from anywhere. A remote image in an email quietly tells the sender when you opened it and roughly where you were; ours cannot, because there is nothing in it to load.
You can turn each kind off — matches, messages and likes separately — and turning them all off does not affect security or account emails such as your sign-in code, which are how you get in and how we tell you something has gone wrong.
If you ask us to email you at launch
Our website has a form for people who would like one email when Flare launches. Using it does not create an account, and you do not need it to join: you can create an account today, even though Flare has not yet opened to the public — which is what the rest of this policy means by launch.
What we keep: the email address submitted, the date and time it was submitted, which version of the form's wording was in use at the time, and a marker that it arrived through the website. Those four things are the whole record — not your name, and no account identifier. But the address itself is in it, so if you also have a Flare account under the same address, the two could be matched up by anyone able to read both.
Separately, our website host and Supabase keep ordinary request logs that include the IP address a submission came from. Those are kept under those companies' settings rather than ours, and they are not part of this record.
What we use it for: sending you one email when Flare opens to the public. Nothing else — no newsletter, no marketing, and we do not sell it or pass it to anyone to use for their own purposes. The companies that hold it on our behalf are in "Who else handles your data". It is not added to an account.
Why we hold it: your consent. You tick a box that starts unticked, and the form will not take an address until you do. Being exact about the limit of that, because it matters: the form cannot check that whoever ticks the box owns the address, and the part of our website that stores an address can be reached directly without the form at all. So some addresses on this list may be there without their owner having agreed. We therefore do not treat a submission as permission to do anything beyond the single email described below — which says how the address reached us — and where an address is on the list without its owner's agreement, we have no reason to keep it and will delete it as soon as we are asked.
How long: until that email is sent, after which we delete it by hand — there is no automatic step — and no more than 12 months in any case. See "How long things are kept", including why that 12-month limit is not yet enforced by anything either.
If someone else entered your address: the form cannot check that an address belongs to the person submitting it — and the form is not the only way in, because the part of our website that stores an address can be reached directly by an automated request that never shows anyone a form or a tick-box. So an address can be on this list without its owner ever having been asked. If that is you: it sits in our database as described above, with no automatic expiry running today, and you would have no way of knowing until we emailed you at launch. That email will say how the address reached us. Ask us and we will delete it.
Changing your mind: email support@myflaredating.com and we will delete it. We reply to the address itself, so that nobody can use us to find out whether somebody else is on the list. Creating — or deleting — a Flare account does not change this record either way, so if you want it gone, tell us.
Sharing a date with someone you trust
If you match with someone, either of you can send one trusted contact a link showing who you are meeting and where. It exists because meeting a stranger is the riskiest moment this app arranges, and telling someone where you'll be is the oldest precaution there is. This is the one place in Flare where information about a user reaches somebody who does not have an account, so it gets a section of its own rather than a line.
What the person who opens the link sees: the other person's first name, the venue you typed, when the link stops working, and — only if you chose to add one — your own phone number, so they can call you. The app does not currently collect a meeting time, so none is ever shared — if that changes, this page will say so.
What they do not see, and this list is enforced by the database rather than by the page: no photo, of either of you. No profile. No more than the first word of the name they entered — a single word is what shows if that is all they entered, so this is minimisation rather than a promise about surnames. No location or coordinates, ever — this is a snapshot of what you typed, not tracking, and nothing about where either of you actually is is transmitted, stored or checked at any point. No message. No email address. No link into the app, and nothing that identifies either account.
The link dies on a clock, and four other things kill it early. Every link lasts four hours. There is no setting for this — our system refuses to issue one lasting less than fifteen minutes or more than twelve, but the app does not currently offer you a choice within that. It also ends the moment you end it yourself, the moment either of you blocks the other, if we restrict either account, and when you create a new link for the same person — the old one dies immediately. Expiry does not depend on any scheduled job running: the page checks the clock every single time someone opens it, so a dead link is dead even if everything else in our infrastructure has stopped. After it ends, anyone opening the link is told only that it has ended, and gets none of the details above — including people it worked for five minutes earlier.
Now the part that concerns you as the person being shared, which is the half a policy is tempted to leave out. If your match uses this, your first name and the venue go to somebody you have not met, and you are not told. We thought about notifying you and decided against it, for two reasons we would rather state than hide. The first is that a notification is itself a hazard: in the small number of cases this feature exists for, telling someone that their date is being watched changes what they do rather than deterring it, and identifies the person who did not trust them. The second is that a safety tool announced to the person you are being safe about will not get used, and then it protects nobody. So the disclosure happens here, at the level of the category, to everyone who reads this page — because everyone on Flare is both people in this arrangement.
Our lawful basis for that is legitimate interests — your physical safety and your match's. We assessed it as passing for a name and a venue, and as failing for a photo, which is exactly why no photo appears on the page: a contact needs to know who you're meeting and where, and a photograph adds nothing to raising the alarm while making a forwarded link far more harmful. The phone number passes the same test only because it is optional and only you decide to add it: it exists so your contact can call you directly if something feels wrong, which is the whole point of telling them in the first place — but nobody's phone number is shared unless the person it belongs to chose to put it there. You can object to this processing, and you can ask us what has been shared about you — see "Your rights" below.
Anyone the link is forwarded to can open it. There is no password on it and we cannot tell who has it. Treat it as you would a message: send it to the person you mean to send it to.
A share is deleted when either account is — yours or your match's — with no action needed from either of you. We keep the record for 30 days after the link expires, so "did I share that evening, and which venue did I put" can still be answered after the evening rather than only during it. Those two numbers are deliberately different, and the same caveat applies to the 30 days as to the internal records described below: the deletion routine exists and is tested, but nothing runs it on a schedule yet, so today that record is kept indefinitely rather than expiring. That will change at launch. It matters less here than for reports, because the record holds no message text — a first name, a venue, and the phone number if you added one — but it is your evening's plans and you should know it is still there.
A copy of your data includes the shares you created, and not the ones created about you. That asymmetry is deliberate: a share names the other person and is a record of what they were told about, so listing it in your file would tell you which of your matches had been sharing plans that involved you — which is the notification we just explained we are not sending. If you want to know whether you have been named in one, ask us using the contact address below. The copy never contains the link's token, because an export must not be a way to bring a dead link back to life.
Blocking and reporting
You can block anyone. While a block is in place neither of you can see or reach the other — profiles, likes, matches and the conversation all disappear from both sides.
The other person is not notified, and nothing in the app tells them: what they see is what they would see if you had deleted your account. We will not claim more than that, because it would not be true — someone technical enough to inspect our API directly could tell a block apart from a deleted account. What they cannot do is get a list of who has blocked them, or be told when it happens.
Blocking hides; it does not delete. Your conversation still exists in our database, and it comes back if you unblock. It also still appears in a copy of your data, because those are messages you genuinely sent and received. If you want the content gone rather than hidden, deleting your account is what does that.
You can report anyone. When you report someone we take a copy, at that moment, of: the recent messages between you (both sides), any comments they sent with a like, and their profile as it then stood. We do that because otherwise someone can delete their account and erase the evidence of what they did before anyone has read it.
That copy outlives their account, and yours. It is intended to be kept for 24 months from the report and is not removed when either of you deletes your account. Our basis is being able to act on a safety report and justify what we did — including to the regulator, if asked.
The same caveat applies to that 24 months as to the internal records described below, and we would rather repeat ourselves than have this one read as firmer than it is: the routine that deletes expired reports exists and is tested, but nothing runs it on a schedule yet, so today a report is kept indefinitely rather than expiring at 24 months. That will change at launch. It matters more here than elsewhere on this page, because this is the record that contains message text.
It is one of several things described here that survive account deletion — this, content moved to restricted storage during an investigation (below), the verification record below, the scrambled form of your email address in the anti-abuse counters, the payment reference described under your rights, and an address given for a launch email.
Reports about you are not shown to you and are not included in a copy of your data. They identify the person who reported you, and disclosing that would put them at risk. Reports you file are in your own copy, without the evidence snapshot — that snapshot is mostly the other person's messages, which already appear in your data as messages you received.
If we restrict an account after a report, we keep a record of that decision, which also outlives the account.
When an investigation pauses deletion. If we are investigating a report that content on an account may be unlawful or may put someone at serious risk, then while that investigation is open we may stop the account's owner from deleting the account, and from adding, editing or removing its photos, profile and prompt answers. We may also take all of the account's photos off Flare, together with text on the account that we are investigating — such as a bio, prompt answers, like comments and messages — and move them to restricted storage that no member can reach and the app cannot show. Content moved there is not deleted when the account is, and nothing deletes it automatically: we delete it once any period for which the law requires us to preserve it has ended and we have reported the matter to the authorities, or sooner if our legal advisers direct us to. If the investigation finds the report was mistaken, we return the photos to the account; text we removed is not restored. The pause on deleting and editing ends when the investigation is closed.
What we are not promising: a response time, and not a reading time either. A report does raise an alert to the moderation mailbox, which is monitored, but Flare has not launched and there is no staffed rota with a committed checking cadence — an alert nobody has committed to reading on a schedule is not the same thing as a service-level promise, so we are not going to state a number we cannot back. If you are in immediate danger, contact your local authorities rather than waiting for us.
How long things are kept
- An address you gave us for a launch email — until that email is sent, then deleted; and in any case for no more than 12 months after you gave it. The time limit is meant to be enforced by a scheduled clean-up, and that clean-up is not yet switched on — until it is, the limit depends on us doing it, so if you want the address gone sooner, ask us and we will delete it.
- Profile, photos, prompt answers and verification data — for as long as your account exists. Deleted with it, automatically, when you delete your account, except as in the next item.
- Content moved to restricted storage during an investigation — until any period for which the law requires us to preserve it has ended and we have reported the matter to the authorities, or sooner if our legal advisers direct us to; then deleted, by a person rather than automatically. It is not deleted when the account is. See "When an investigation pauses deletion" above.
- Likes, matches and messages — for as long as either of you has an account. Deleted automatically when either person deletes theirs.
- Blocks — while the block is in place, and until either account is deleted. Unblocking removes the record of it.
- A date you shared with a trusted contact — the link stops working after 4 hours (our system will never issue one lasting more than 12), or sooner if you end it, if either of you blocks the other, or if we restrict either account. The record of it is intended to be kept for 30 days after that, and is deleted when either account is. Those are two different numbers on purpose, and only the first one is enforced without a scheduled job — see "Sharing a date with someone you trust" above, including what "intended" is doing in that sentence.
- A restriction on your account, if we ever apply one — while your account exists. A minimised record that we restricted it, and when, is kept for 24 months as part of the internal records below, because we have to be able to account for that decision.
- Reports and their evidence copy — see above. These are not deleted when an account is (nor is an address given for a launch email, listed at the top, nor a record of a payment).
- A record of a payment you made — kept as a financial record and not deleted with your account, the same way a business keeps a receipt. No retention period is set for these yet; see "Who else handles your data" above for what the record contains.
- Your signed-in session — 30 days maximum, and 7 days of inactivity ends it sooner. Enforced automatically.
For internal records — the audit trail of account deletions and verification decisions, records of data-export requests, records of any moderation action taken on an account, and records of operational failures and anti-abuse counters — the intended retention periods are 24 months for the first four, 6 months for operational failures, and 24 hours for the counters.
Being precise about that word "intended": the deletion routines exist and are tested, but nothing runs them on a schedule yet, because that requires infrastructure this app does not have until launch. So today those internal records are kept indefinitely rather than expiring on the dates above. They contain no photos, no location and no message content — but stating a retention period we do not yet enforce would be telling you something untrue, so this is what is actually happening.
That includes the scrambled form of your email described above, and it is the one item here that is not removed when you delete your account. It sits in the anti-abuse counters rather than in your profile, so the deletion routine does not reach it, and the 24-hour expiry that would have cleared it is one of the schedules not yet running. It is a hash and nothing else — no address, no name, no content — and it will expire on that 24-hour window once the schedule is switched on at launch.
The verification record that outlives your account
When you delete your account, your profile, photos, location, prompt answers and the verification record itself are erased — apart from any content moved to restricted storage during an investigation, described under "Blocking and reporting".
With one deliberate exception. If you completed identity verification, a minimised record of it is kept for 24 months: the decision, the ID type, a masked reference, the provider's name, the time you gave consent, when the verification was created and last updated, and two internal identifiers — one for the verification and one for your (now deleted) account.
It contains no ID number, no email address, no photo, no location and no message content. It is linked to your deleted account only by that internal identifier, not by anything that names you — though we should be straightforward that the identifier is not meaningless: the two residues listed further down (the sign-in log, and un-expired backups) could in principle be used to connect it back to you.
Nigerian data-protection law requires FLARE DATING LIMITED to be able to demonstrate that it obtained valid consent before running an identity check. Before this record existed, deleting an account destroyed the proof of that consent — which meant exercising one right destroyed the evidence for another.
This means a deletion request cannot remove that particular record. You are entitled to know that, which is why it is stated here plainly rather than buried.
Three things kept longer than we would like
Stated because they are true, not because they are flattering:
- The authentication system keeps its own log of sign-in events, which includes an email address and IP addresses, and it is not currently cleared when an account is deleted.
- Database backups have no automatic expiry, so a backup taken before a deletion still contains that data until the backup is removed.
- As described above, the automatic expiry of internal audit and anti-abuse records is not yet running, so those records currently persist rather than ageing out.
All three are known and tracked. None is used for any purpose beyond keeping the service running, recoverable and free of abuse.
Who else handles your data
- Supabase provides the database, file storage and authentication. All of the data above is held there, in a region outside Nigeria — so using Flare involves an international transfer. An address you gave us for a launch email is held there too.
- Vercel hosts this website and serves every page of it. Like any web host, its request logs record the IP address a page was requested from, together with the time and the page. That happens for every visit, including before you have signed in, and those logs are kept under Vercel's own settings rather than ours.
- Hostinger sends our email — your sign-in codes, and the notifications about matches, messages and likes — relaying through MailChannels to deliver it. Anything we email you passes through them, including the address you used to sign in.
- The launch email has no sending service chosen yet. When one is chosen it will be named here before it is used to send anything. It is most likely to be Hostinger, above, in which case no new company is involved — but that is not decided, and this says so rather than assuming it.
- Dojah provides identity verification, and is connected to Dojah's live service. When you submit an ID for verification, your ID number is sent to Dojah, and Dojah returns the government record it holds for that ID — a real record from the official register, not test data. Your name and date of birth are compared on our side and never leave Flare. Dojah holds its own record of the check under its own retention rules, which Flare cannot delete on your behalf. Production access was granted and the live connection was made in September 2026; before that date, checks ran against Dojah's test environment and returned simulated data rather than a real government record. One consequence is worth stating plainly. A small number of accounts carry a "verified" badge that was granted by hand during development, or by a check that ran against the test environment, rather than by a live check against the official register. Those badges are being reset so that the badge means one thing only. We say so here rather than let the badge imply more than it does.
- Paystack processes any payment you make on our website, and handles your card details directly — Flare never receives or stores a card number. Memberships are paid. One bought on our website is a single payment for a single period: a website purchase never renews by itself, so we do not charge you again unless you buy again. A verified webhook writes an append-only financial record of the transaction — the payment confirmation Paystack sends us, kept as it arrived. It includes the amount, the currency, Paystack's own references, the email address the payment was made with, and the card authorisation Paystack issued. It never includes a card number: Paystack handles the card and we never receive it. Where Paystack returns one, we also keep the card authorisation it gives us for that payment, together with the email address that authorisation is bound to. Your data export tells you what Paystack told us about whether that authorisation can still be charged, and which address it is bound to; the authorisation itself is deliberately left out of the export, because it is the part that could be used to charge you. When you delete your account we ask Paystack to deactivate that authorisation. That call is deliberately not allowed to block your deletion, so if Paystack cannot be reached the deletion still goes through and the request is raised to us instead. The financial records themselves are not deleted with your account, the same way a business keeps a receipt after a customer leaves; everything else about you still is.
There is no analytics, no advertising, no third-party tracking and no session recording in this app. Cookies are used only to keep you signed in — there are no tracking or advertising cookies, which is why you are not asked to consent to any. (The sign-in cookie is split across more than one entry when it is large, and a short-lived extra one is set while your emailed code is being exchanged.)
Automated decisions
Matching is rule-based and deterministic — shared interests, stated preferences, and distance. There is no machine learning, no profiling that produces a legal effect, and no AI feature.
Bios, prompt answers, like comments and messages are also checked against a list of words and phrases we maintain before they are saved. This is a simple text match, not AI, and if it refuses something, the text you tried to post is not saved.
Your rights, and how to use them today
Two are already built and work without asking anyone:
- Download my data — one file containing everything in the app's own database about you, including working links to your photos. Three honest caveats: the audit-trail section is capped at a maximum number of entries (the file tells you when it has been truncated); it cannot include the authentication system's separate sign-in log, which is the first residue listed above; and it leaves out a small number of values that are credentials rather than facts about you — the stored card authorisation and the payment processors' own customer and purchase references — because handing those back in a file would create the risk the export exists to avoid. It also does not include content moved to restricted storage during an investigation.
- Delete my account — immediate and permanent, photo files included, subject to the exceptions described above — which include an address you gave for a launch email, and an account under an open investigation, which cannot be deleted until that investigation is closed.
Neither reaches an address you gave for a launch email, whether or not you have an account: that record is not attached to any account, so there is nothing for those two buttons to act on. Email support@myflaredating.com and we will delete it — we reply to the address itself.
Both are on your dashboard when you are signed in. To correct anything, edit your profile — or, while an investigation described above has paused editing, email us.
Other rights, and how they work in practice today. You can ask us to stop processing your data, or object to it — in practice, for an app like this, deleting your account is almost the whole of both, and it is self-serve. It does not reach an address you gave for a launch email; email us for that. You can withdraw consent for identity verification, but note that there is no button for that yet: email us and we will remove the verification. The consent record described above still cannot be removed, for the reason given there.
Why we hold each thing: your profile, photos and prompts because you asked us to provide the service; identity verification on your explicit consent, and to meet a legal obligation to check age and identity; the audit trail and anti-abuse counters because we have a legitimate interest in a service that is safe and accountable.
One gap worth disclosing rather than hiding. Supabase holds all of this data and is outside Nigeria, and a formal data-processing agreement with them has not yet been signed. It is being arranged. Until it is, that international transfer rests on their published terms rather than on a contract specific to Flare — and since we are responsible for our processors either way, you should know that.
You can also complain to the Nigeria Data Protection Commission at ndpc.gov.ng.
Age
Flare is for adults: you must be 18 or older. This is enforced by the database when your profile is created — an under-18 date of birth is rejected outright, not merely discouraged — so no usable profile can exist for a minor.
Contact
Email support@myflaredating.com.