The Registration Flow I Couldn't Build

It took me months to figure out the best registration flow. Countless Miro diagrams, user journey maps, and various prototypes. Zero thinking required, users would just enter information naturally and indicate whether or not they are registering themselves, or on behalf of someone else as the system would intelligently adapt to who they were - and athlete or a parent. Forms would scaffold themselves based on context. Age would determine which fields appeared and everything would be smooth.

Then I learnt about COPPA (Children’s Online Privacy Protection Act) guidelines.

Then I realized I couldn’t build what I’d envisioned - not without creating potential legal liability. Something that i’m unfamiliar with and definitely want to avoid.

Note: This article describes technical decisions based on our understanding of COPPA and related regulations. It’s not legal advice.

The Vision

The goal here was simple: create a registration flow that could easily use the information provided (guardian vs athlete) and adapt the form dynamically without too much explicit user input. They would see one simple prompt: “Let’s get you registered.”

Once the system knew if they were an athlete or the guardian registering on their behalf, it would adapt the rest of the form accordingly.

They start entering information. First name, last name, email. As they type their birthdate. The form adapts. New fields appear asking for parent information, or asking the athlete for their experience in the sport. No cognitive load. Just smart scaffolding.

The system collects exactly what it needs based on who’s filling out the form. An adult registering themselves gets one experience. A parent registering their child gets another. A 15-year-old athlete registering on their own gets a third variation. All from the same starting point.

I spent way too long architecting this flow with countless prototypes, when screen should pop up, and when different flows should be used. Database schemas designed to support dynamic form generation. Frontend logic that would adapt in real-time. State management to handle the complexity of branching paths without losing user progress.

Then I started looking into data privacy regulations around the world and came across COPPA which specifically governs data collection from children under 13 in the United States. As the initial target market for Enagon Athletics is based in North America, figured this was a good place to start.

What is it? COPPA and the Reality of Youth Data Protection

The Children’s Online Privacy Protection Act (COPPA) exists for good reason. It protects children under 13 from having their personal information collected, used, or disclosed without verifiable parental consent.

Here’s what COPPA requires if you want to collect personal information from a child under 13:

Verifiable Parental Consent (VPC)

You can’t just ask for parent consent. You need to verify that the person giving consent is actually the child’s parent or legal guardian. The FTC provides several acceptable methods, none of which are trivial:

Credit card verification
Video conferencing with ID check
Signed consent forms submitted physically
Government-issued ID verification
Knowledge-based authentication

Implementing this is non-trivial. It adds friction to the registration process and requires secure handling of sensitive information. It’s definitely not something I could just slip into my workflow without significant overhead. Also, this is just the registration for a CHANCE to join a sports program - not exactly a high-value transaction that justifies complex verification.

Data Minimization

You can only collect information that’s reasonably necessary for the activity. No “just in case” data collection. Every field needs justification. Every piece of information stored creates compliance burden.

The 2025 amendments made this even stricter. The FTC now expects you to demonstrate that you’ve considered less invasive alternatives before collecting any data from children.

These are great moves in terms of data privacy, but it definitely complicates my ideal registration flow. Or so I thought.

Ongoing Obligations

Once you collect data from a child, you have continuing obligations:

Allow parents to review the data you’ve collected
Provide ability to delete the data
Not condition participation on collecting more data than necessary
Maintain reasonable security measures

My Perfect Flow Violates COPPA

Let’s trace through my ideal registration flow with COPPA in mind.

Step 1: User starts entering information

Already problematic. If a child under 13 starts entering their own information before we’ve obtained verifiable parental consent, we’re in violation the moment they submit a birthdate indicating they’re under 13.

Step 2: System detects they’re a minor and scaffolds accordingly

Too late. We’ve already collected personal information (name, email, birthdate) from a child without parental consent. The FTC doesn’t care that we detected it and changed the form. We already violated the rule.

Step 3: System asks for parent information

Even if we tried to get consent at this point, it’s not verifiable parental consent. We have no mechanism to confirm the person entering parent information is actually the child’s parent. A 12-year-old could easily enter fake parent details and continue.

The International Dimension Makes It Worse

COPPA isn’t the only regulation to worry about. The global landscape for youth data protection is getting stricter:

South Korea’s PIPA

Children under 14 require verifiable parental consent under South Korea’s Personal Information Protection Act. Similar principles to COPPA but with different verification requirements and enforcement mechanisms.

UK Age Appropriate Design Code

Requires services likely to be accessed by children to implement age-appropriate safeguards by default. This shifts the burden—you need to assume children might access your service and design accordingly.

California’s CCPA Age Provisions

California of course has their own additional rules to protect minors.

Additional protections for minors under 16, though less stringent than COPPA for the under-13 group.

Building one flow that works everywhere is nearly impossible without making the experience terrible for everyone.

But Wait, Can’t We Just?

After taking a step back and trying to reimagine the flow, I realized that this actually made the enter workflow easier.

Trying to better understand from the COPPA FAQ,

“COPPA only covers information collected online from children. It does not cover information collected from adults that may pertain to children.” (FAQ F.4)

This key insight helped me simplify the problem and made it super easy to implement a compliant registration flow. I just needed to assume the guardian was the primary registrant for anyone who might be under 13 which would then defer the collecting of detailed athlete data from the under aged athlete until later when proper consent and data management could be applied.

How it works:

Default Assumption: Registration starts with the assumption that an adult (parent/guardian) is registering someone else (potentially a minor). For now we are targeting youth sports, so the guardian and athlete relationship is the default - later on for sure there are scenarios where an adult athlete registers themselves, but those are less common in youth sports.
Minimal Initial Collection: During registration, we collect only what’s absolutely necessary from the guardian: their contact information, their relationship to the athlete, and basic team selection. We explicitly do NOT collect detailed athlete information at this stage.
Post-Registration Data Collection: After registration is complete and we’ve established the guardian relationship, we can work within a clearer consent framework. The guardian has created an account. They’ve verified their email. They’ve established themselves as the responsible party.
Age-Gated Athlete Details: When it’s time to collect athlete information (which might happen during onboarding or before the first practice), we can now do so through the athlete’s own profile within the guardian’s account. If the athlete is under 13, we can implement verifiable parental consent mechanisms at this stage, knowing that the guardian is already authenticated and responsible.

Why this works legally:

We’re not collecting data directly from children
The parent/guardian relationship is established before detailed athlete data collection
We can implement proper consent flows after the initial registration hurdle
Data minimization is easier when we’re not trying to do everything at once

Why this works practically:

Simpler to implement and maintain
Clearer user mental model (you’re registering as a guardian)
Easier to scale when regulations change

This approach powers Enagon Athletics’ registration system today. When a parent creates an account, they’re establishing themselves as the guardian first. Only then, through their authenticated account, do we collect athlete-specific information with proper consent frameworks in place. The athlete will have their own account of which we can manage as needed.

The Balance: Protecting Athletes While Building Products

Youth sports registration systems have a responsibility beyond smooth UX. We’re collecting information about children. We’re building profiles of young athletes. We’re creating data that, if mishandled, could put kids at risk.

COPPA and similar regulations aren’t just obstacles, but are also the guardrails that force us to think carefully about what we’re collecting and why. This extra layer is something that many early engineers may miss when building products, not only for the youth, but in general when tying more and more legal requirements into product design.

The system I built isn’t the one I initially envisioned. It’s better. Not because the UX is smoother, but because it respects the reality that we’re dealing with children’s data. It acknowledges that parents should be in control. It minimizes data collection to what’s actually necessary.

We shouldn’t be opening with statements like “Check out this magical registration flow.”, but rather lead with “We take youth data protection seriously. Here’s how our system keeps your athletes safe.”

That’s a better pitch. More importantly, it’s the truth.

Key Takeaways

COPPA compliance isn’t optional: If you collect data from children under 13, you need verifiable parental consent and ongoing compliance infrastructure
Perfect UX sometimes conflicts with compliance: The trade-off is worth it when the alternative is legal liability
Use specialized auth services: Supabase, Auth0, and similar platforms handle the complex security work so you can focus on your product (depends on your use case)
Data minimization protects both users and your business: Collect only what’s necessary, only when it’s necessary for ethical computing!
International regulations are converging toward stricter standards: Keep this in mind when designing products

What’s Next

Does this mean we’ve abandoned the dream of frictionless registration? Not entirely. Within the guardian-first framework, there’s still room for smart defaults, progressive disclosure, and contextual help. We just build those conveniences after establishing the legal foundation, not instead of it.

About This Series: This article is part of an ongoing exploration of the real-world challenges in building sports technology for youth athletes. Future articles will cover data architecture decisions, scaling registration systems, and balancing feature requests with compliance requirements.

Questions or feedback? Reach out at [email protected]