Privacy Policy

D-You · Version 1.0 (draft) · August 4, 2026 · pending legal review

Operated by The Little Guy LLC ("we", "us"). Contact: support@dyou.pro · 336 East University Pkwy #1043, Orem, UT 84058.

This policy describes what we actually collect, why, how long we keep it, and who touches it. It is written from the way the product is built, and it is deliberately specific: our product holds a child's growth and performance record, and the family that trusted us with it is owed more than boilerplate.

The short version

• The account belongs to the parent. Children cannot create accounts, cannot sign in on their own, and never receive email from us.
• We collect only what changes the card: the athlete's first name, their age, sex (for the growth reference), height, weight, optional wingspan, parental heights, and their sport results. Nothing else is asked for.
• We do not ask for a child's date of birth in football or basketball — month and year only. The growth model steps in half-years, so the day adds no accuracy, and a full date of birth is an identifying field we would then have to protect for nothing.
• We do not sell personal data. We show no ads. We use no third-party analytics or advertising trackers. Children's data is never used for advertising or to train models.
• Every retention period is written down (below), enforced in code, and nothing is kept indefinitely.
• The parent can review everything and delete everything, immediately, from the parent dashboard.
• Three service providers touch data, each for one job: Stripe (payments), Resend (transactional email to adults), Supabase (database and sign-in infrastructure).

1. The account is parent-owned

One account per family, created by the parent with their email and a password. Everything about an athlete is entered by the parent, inside the parent's signed-in account. There is no child-facing login, no child-facing email, and the athlete's view of their own card carries no purchase prompts — billing, sharing, verifier invites, and deletion controls exist only in the parent's view.

This structure is our COPPA posture in one sentence: the parent is the only person who can put a child's data into this product, and the only person who can take it out.

2. What we collect, and why each item exists

From the parent, at signup: the parent's email address and a password. The password is handled by our authentication provider (Supabase Auth) and stored only as a hash — we never see or store it in readable form.

About the athlete, entered by the parent:

- First name (display name) — so the card is theirs. We do not ask for a surname. - Sex (M/F) — selects the growth reference population (CDC growth references and the Khamis-Roche projection method are sex-specific). We do not collect race or ethnicity; the wingspan correction runs sex-specific only, and the product documents that as a known limitation of the method rather than collecting more demographic data to "fix" it. - Age — an input to every growth calculation. How much we ask for depends on the sport, and we ask for the least that works: - Football and basketball: birth month and year only. No day. The projection resolves to about half a year, so a day buys roughly a fortnight of precision the method cannot use — and it would make the record more identifying for no gain. - Swimming: full date of birth, because that flow was built earlier against age-group meet eligibility, which is date-specific. We intend to bring it in line with the above. - Height, weight, optional wingspan — the anthropometric inputs, along with how they were measured (to protocol or from memory), which the product tracks as measurement provenance. - Parental heights (and whether each was measured or estimated) — an input to the Khamis-Roche adult-height projection. - Sport, position, and results — the performance inputs behind every comparison. What this means depends on the sport: - Swimming: event times with the timing method (hand time, FAT). - Football and basketball: the position or role, published season statistics, the season those statistics came from (recorded separately from the athlete's current grade, so we never compare a 15-year-old's numbers to an 18-year-old's), and optional combine measurables such as a 40-yard dash — always stored with how it was timed, because a hand time and a laser time are not the same number. - School context — state, school name, classification, team level, and season record. This describes the competition the results came from. School name is optional. - Re-measurements — the same fields again over time, which is what makes the growth record longitudinal.

Derived, not collected: maturity estimates (percent of projected adult stature), the projected adult height range, growth-chart percentiles against named reference populations, and the card's signature-strength/limiting-factor analysis are computed from the inputs above using published methods. We do not collect maturity staging of any kind.

If the paid tier is used:

• Training check-ins — which sessions were done, an optional effort rating and note, and free-form activity logs.
• Habit check-ins — sleep, fueling, and training consistency as simple yes/no check-ins. By deliberate design, enforced in the database schema itself: no calorie counts, no macros, no diet detail, and weight is never part of habit tracking.

The eating-concern screen never reaches us. The short screen shown before training features is answered on the athlete's device; the individual answers are not transmitted to or stored on our servers. The only thing that exists afterward is a browser cookie holding a single word — flagged or clear — which expires after 90 days and controls only whether training-adoption features are softened in that browser.

If the parent invites a verifier (coach, mentor, or peer): the verifier's email address (to deliver the invite), the role the parent assigned, the display name the verifier chooses, and a log of every attestation they make (which mark, what action, when). Verifiers are adults chosen personally by the parent.

Billing: handled by Stripe. We store the Stripe customer identifier and subscription state (plan, status, renewal date). Payment card numbers are entered on Stripe's pages and never touch our servers.

What we deliberately do not have: no third-party analytics, no advertising trackers, no photos, no contact lists, no precise location. Our cookies are limited to the sign-in session, the currently-selected athlete, and the on-device screen result described above.

3. Why we process any of this

One purpose: to produce and maintain the athlete's card and its analysis for the family — the growth record, the maturity-adjusted context, the standards ladder, and (on the paid tier) the training, habit, and progress features. The intake asks only for fields that change that output. We have no secondary uses: no advertising, no data sales, no profiling beyond the card itself, and no training of models on children's data.

4. Parental consent

The account is created by the parent; every field about the athlete is entered by the parent inside that account; and disclosures about method limitations and data practices are shown at intake and remain permanently visible in the parent dashboard (this policy included — disclosed in the product, not buried in a footer). Nothing about a child is collected before the parent has created the account and chosen to enter it. [The precise verifiable-parental-consent mechanism for the free tier is under legal review — see the note to counsel at the end of this document.]

5. How long we keep things — the written retention schedule

These periods are quoted from our written retention policy (v1.0, July 26, 2026), which exists as configuration in the running system; the dashboard's retention panel is served from the same source the deletion job reads. The principle: a retention period is an argument about purpose, not a number we liked.

• Measurements and maturity assessments (the longitudinal record) — kept while the account is in use; purged after 730 days of inactivity, or immediately on parental deletion. Why: "This is the product. Growth tracking and the maturity-adjusted progress view are only meaningful across years, so a fixed rolling window would destroy the thing the family is paying for. The honest limit is therefore use, not age: two years with no measurement, no check-in and no card render means the family has gone, and there is no purpose left to point at."
• Habit check-ins — 365 days, rolling. Why: "Nothing in the product reads past roughly twelve weeks — streaks and weekly consistency are short-horizon by design. A year is already generous; it exists so an athlete can compare one season to the last."
• Training logs — 365 days, rolling, for the same reason.
• Measurement submissions (the provenance trail) — 730 days, rolling. Why: "It is what lets us explain how a figure on the card was derived, which we may be asked to do long after the fact. Kept longer than engagement logs, still expires."
• Card render log (the substantiation record) — 730 days linked to the athlete, then irreversibly pseudonymized — see section 6.
• Account and athlete records — until deleted by the parent, or after 730 days of inactivity.
• Anything, on parental request — deleted immediately.

Activity is derived from actual use (recent measurements, check-ins, or card renders), not from a stored "last seen" field, so a family still using the product can never be purged by a stale flag. Deletion runs are idempotent and ordered so that a partial failure can never leave inconsistent state.

6. The card render log, and why part of it outlives deletion

Every time we display an athlete's card, we record what was claimed on it — each percentile shown and the named reference population that backed it, with a timestamp. This is our substantiation record: it is how we can prove that every claim we displayed was backed by a named reference at the moment it was made. It is a record we keep about our own conduct, and U.S. advertising-substantiation law expects us to be able to produce it.

Because it is also a per-child record of what a child was shown, it does not get to live forever in that form. After 730 days — or immediately, before any parental deletion cascade — the row is pseudonymized: the links to the athlete and their assessment are overwritten with nothing. This is irreversible by construction (there is no key, lookup table, or hash that could reconnect it), a database constraint makes a half-pseudonymized row unrepresentable, and the surviving fields (claim, reference population name, timestamp, sport) were verified to contain nothing identifying. After that point the row is a record about our claims, not about your child.

When you delete your athlete's data, this is the one thing that is pseudonymized rather than erased — and the receipt you get itemizes exactly that.

7. Your rights as the parent, and how to exercise them

All of these are buttons in the parent dashboard, not support tickets:

• Review — the dashboard shows everything held about each athlete; the profile page shows the raw stored inputs; the retention panel shows this schedule.
• Delete — "Delete [athlete]'s data" removes the profile, measurements, assessments, sport seasons, habit and training check-ins, adopted routines, and verifier links immediately, and shows a receipt itemizing what was removed (and how many render-log rows were pseudonymized). It cannot be undone. The parent account itself survives — it may hold siblings and it is the consent record; an account left unused is collected by the inactivity rule.
• Revoke a verifier — any invited seat can be revoked at any time; the link stops working immediately, and every attestation ever made through it remains logged and attributed.
• Cancel a subscription — "Manage or cancel subscriptions" in the billing panel, no retention flow.
• Anything you cannot do with a button: support@dyou.pro.

8. Who data is shared with

Three processors, each for exactly one function:

• Stripe — payment processing and subscription billing. Stripe receives what a payment requires (and card details go to Stripe directly, never through us). Stripe also sends payment receipts and renewal notices for our subscriptions.
• Resend — delivers our transactional email. Our email system has a closed allowlist of message types — currently exactly one: the verifier invitation, sent to the adult the parent chose. It goes to the parent's chosen recipient, never to an athlete; we send no marketing email to anyone.
• Supabase — hosts our database and provides parent sign-in (authentication). Data lives in Supabase-managed Postgres with row-level security policies scoping every row to the owning parent.

We do not sell personal data, share it for advertising, or provide it to data brokers — for children or adults, ever. We use no advertising networks. We do not use personal data to train machine-learning models; the card's mathematics are deterministic published methods (Khamis-Roche, CDC growth references, published time standards), not learned from users. If we are ever legally compelled to disclose data, we will disclose the minimum required and, where lawful, tell the parent.

9. Security

• Every database row about a family is bound to the parent's account by row-level security policies, and the API independently checks ownership on every request — two layers, either of which alone would enforce isolation.
• The production build refuses to start if authentication is off, if development credentials are present, or if a test payment key is configured. A misconfigured deployment fails loudly instead of running open.
• Passwords are hashed by Supabase Auth; we never handle them in readable form. Payment card data never reaches our systems.
• Verifier links are scoped to exactly one athlete, revocable, logged, and rate-limited against implausible activity.
• Billing webhooks are cryptographically signature-verified; nothing about entitlements is trusted from a browser redirect.
• Secrets live outside the codebase, with automated scanning in place to keep them out. All traffic is encrypted in transit (TLS) in production.

No system is perfectly secure. If a breach affects your family's data, we will notify the parent email on the account as required by law.

10. Changes to this policy

If we change this policy in a way that matters — new data collected, a new purpose, a new processor, a longer retention period — we will notify the parent email on the account and post the change here before it takes effect. Lengthening a retention period requires a new version of the written retention policy, not a quiet edit.

11. Contact

Questions, requests, or complaints: support@dyou.pro · 336 East University Pkwy #1043, Orem, UT 84058. Parents can exercise every data right directly from the parent dashboard at any time.