Legal
Effective 6 August 2026
This is a description of a specific piece of software rather than a generic notice. Everything below is what the code does today. Where a capability does not exist, it is named as missing instead of being written around.
Two different relationships run through this product, and nearly every question about your data depends on which one you are in.
If you are a gym member, your academy decides what to record about you and why. They are the ones responsible for it. We hold it for them and act on their instructions. In data protection terms they are the controller and we are the processor. In practice this means requests about your record go to your gym, and they have the buttons.
If you run an academy, we hold your own account details directly and we are responsible for those.
Academies cannot see each other. Every query in the app is scoped to one academy, and staff belong to the academies they were invited into. To be exact about the mechanism: this is enforced in the application, not by database row-level security.
Staff type this in; members do not have accounts and never enter it themselves. What actually exists in the database:
| Record | What is in it |
|---|---|
| Profile | Name, email, phone, date of birth, emergency contact name and phone, how they found the gym, and their status on the roster. |
| Family | Which adult signs and pays for which member, the relationship, and the household they are grouped under. |
| Training | Check-ins, bookings and waitlist positions, rank and stripe history with who awarded each promotion, and competition results. |
| Billing | Which plan they are on, charges and their outcomes, retries on a failed card, and class packs bought and used. Card numbers are not among these; see the payments section. |
| Signed records | Waiver signatures and parental consent, each with the exact text agreed to, the typed legal name, the timestamp, the IP address and the browser. |
| Notes | Free text staff write on a profile, with the author recorded. Whatever they type goes in, which can include health information relevant to training. |
There are no member photos. Nothing in the product uploads one, and the only images we store are profile pictures staff choose to add to their own logins.
People who enquire but never join are stored too, as leads: contact details, where they came from, and the follow-up trail. Same rights apply to them.
COPPA governs this and we treat it as the strictest rule in the product.
Children do not use Primodojo. They have no account, no login and no way to enter anything. A child exists here because an adult at the gym created a record for them, and the categories are the ones listed above: name, date of birth, emergency contact, attendance, rank, and whatever a coach writes in a note.
Adding a member under 13 opens a consent requirement automatically, and it stays open until a guardian answers it. The academy sends the guardian an emailed link; the guardian reads the disclosure, types their legal name, and confirms. Until that happens the child is held back from check-in and from every public-facing screen. What gets recorded is the exact disclosure text they accepted, their typed name, the time, the IP address and the browser, plus a stored copy of the page they saw.
A guardian who changes their mind should ask the academy to delete the child's record. That erases the data the consent covered, including the consent record itself, and it takes effect immediately. We are being precise here rather than reassuring: there is no separate switch that withdraws consent while keeping the record, and if you want one, deletion is what the software offers instead.
There is no advertising, no behavioural profiling and no third-party tracking anywhere in Primodojo, so none of it reaches children either.
Your name, email address, and a password stored as a hash rather than as text. Optionally a profile photo. Your academy's own details: name, address, contact information and settings. If you have turned on two-factor authentication, the secret behind it.
For your subscription to us we hold a Stripe customer identifier and the state of the subscription. The card itself lives at Stripe.
If you connect Square as your processor, its access token is stored encrypted rather than in the clear.
Staff who opt into push notifications have a subscription stored per browser, with a device label so the settings screen can show you what to turn off. Members are not offered push at all.
No card number, expiry or security code ever reaches our servers, and none is stored in our database. Card entry happens in fields hosted by Stripe or Square, and what comes back to us is an identifier that stands in for the card.
Your members' dues are charged on your own connected processor account and never pass through us. Their payment data is held by that processor under their terms, alongside ours.
There is no analytics in this product. No Google Analytics, no tracking pixels, no advertising network, no session recording, no fingerprinting. If you were expecting a longer list, this is the short one on purpose.
Our host keeps ordinary server logs, which include IP addresses, for a short period.
When something crashes we send an error report to Sentry, and it is worth describing what is stripped out before it leaves. Request bodies, cookies, and URL query strings all go, which is the important one because the magic links for the member portal, waivers and password resets carry their token in the query string. So do your email address, your IP address, and anything a developer attached to the error. Passwords and payment details are in the discarded parts. Session replay is off.
Every page loads two typefaces from Google Fonts, which means Google sees the IP address of anyone visiting the site.
These are the companies involved in running Primodojo. We do not sell data to anyone, and nobody on this list is an advertiser.
| Company | What they do for us |
|---|---|
| Fly.io | Runs the application servers. |
| Neon | Hosts the database, on AWS in the United States. |
| Amazon Web Services | Object storage for waiver and consent copies and staff profile photos, and email delivery through SES. |
| Stripe | Your academy's card payments if you connect Stripe, and our own subscription billing either way. |
| Square | Your academy's card payments, if you connect Square instead. |
| Sentry | Receives the scrubbed error reports described above. |
| Google Fonts | Serves the two webfonts, and therefore sees visitor IP addresses. |
| Apple, Google and Mozilla push services | Deliver push notifications to staff who opted in. Nothing is sent if push is switched off. |
The United States. The application runs in Virginia and the database is in AWS us-east-1.
If your gym is in the UK or the EU, that is an international transfer, and you should know it before signing up rather than after. We have not yet put standard contractual clauses or a data processing agreement in place, so an academy with a strict GDPR position should talk to us first. We would rather say that than let you assume otherwise.
Everything travels over HTTPS. Our database and storage providers encrypt what they hold at rest.
A member record is in one of three states, and the difference matters more than the word deletion suggests.
| State | What it means |
|---|---|
| Active | On the roster. Kept while the academy is open. |
| Archived | Taken off the roster, upcoming bookings cancelled, everything else kept. Reversible, with no expiry. This is where someone who quit ends up, and it is not a deletion. |
| Erased | Actually gone. Immediate, irreversible, and there is no grace period on it. |
Closing a whole academy works differently on purpose. It is scheduled first, which locks the dashboard and stops the subscription renewing but leaves the records in place, and 30 days later everything is purged: files, member subscriptions cancelled at the processor, rows deleted.
So: 30 days to undo closing a gym, and no window at all on erasing one person, because one is a change of mind and the other is a request we were asked to honour.
There is one exception to that, and it belongs in plain sight rather than in a footnote. We keep backup copies of the database so a failure on our side cannot lose an academy's records, and a copy taken before an erasure still contains the erased data until that copy expires. Backups are kept for seven days and then deleted automatically. If we ever had to restore one, anything erased during that window would come back with it, and we would erase it again.
We do not currently delete a member automatically after a period of inactivity. Their record stays until the academy archives or erases it, or until the academy itself closes.
Both of these run through your academy, because they hold the record and the buttons are in their dashboard. Ask them. If they cannot help, write to us and we will help them.
A copy means a zip of spreadsheets covering your own record: profile, guardians, notes, status history, attendance, bookings, promotions, enrolments, payments, class packs, waiver signatures, consent, competition results, and the enquiry you first came in on. It stops at your record. The gym's own material, its class schedule, rank ladders, staff and curriculum, is theirs and is not part of your copy.
Deletion removes the record and everything hanging off it: attendance, bookings, enrolments, notes, guardian links, promotions, competition results, pack purchases, status history, waiver signatures and consent, plus the stored copies of the documents that were signed.
Three things survive a deletion, and each is deliberate.
A child's own consent record goes with the child rather than being kept as proof. Holding a shadow copy of a child's consent history after being asked to delete it would defeat the reason the record existed.
Correcting something is simpler: ask staff to edit it. It is their dashboard.
Depending on where you live you may have further rights, including under the GDPR or the CCPA, and we do not charge for any of this.
What is actually in place: HTTPS everywhere, passwords stored as hashes, optional two-factor authentication, encryption at rest by our database and storage providers, connected processor credentials encrypted with a separate key, card data kept off our systems entirely, and error reports stripped before they leave.
Signing out ends the session on the server. You can also see your active sessions and end the others from your account settings.
What is not in place, since a security section that only lists wins is not much use: there is no audit log of who read what. We record erasures and member status changes with the person responsible, and reads go unrecorded.
If a breach affects your academy we will tell you, with what we know and what we are doing, rather than waiting until the picture is complete.
The effective date at the top moves whenever this changes. If we start collecting something new, or use something for a new purpose, we will email account owners before it takes effect rather than editing this page quietly.
Questions about this policy, or about your own data: support@primodojo.com. If you are a gym member, your academy will usually get you an answer faster, because they hold the record.
This policy was written by the people who built the software, from the software, and has not been reviewed by a lawyer. We would rather say that than imply a review that has not happened.