Making a Youth Sports App COPPA-Compliant: The Real Process From Question to Production

Posted on Oct 8, 2025

When you’re building an app that tracks data for children under 13, there’s a moment where you realize: this needs to be legally bulletproof before it sees a single real user. For Hustle, our youth soccer statistics tracking platform, that moment came today.

This is the complete story of implementing COPPA-compliant legal infrastructure - not the sanitized “here’s how it works” version, but the real process: the questions I asked, the approaches we tried, what failed, and what finally worked.

The Starting Point: “Without These, You Can’t Launch”

The conversation started with a simple reality check:

“We need Terms of Service and Privacy Policy before launch. COPPA-compliant.”

I knew this was coming. Hustle lets parents track their kids’ soccer game statistics - goals, assists, playing time. That means we’re collecting data about minors. That means COPPA (Children’s Online Privacy Protection Act) applies.

My first question revealed where my head was at:

Me: “Why can’t it be by just registering they consent?”

I was thinking about UX. Nobody wants to click checkboxes. Could we make the act of clicking “Create Account” serve as legal consent?

Answer: “Yes, by registering they confirm.”

That simplified everything. No checkboxes needed - just clear legal language with links to the actual documents.

The Technical Requirements

We needed four things:

  1. Terms of Service page - Full legal document
  2. Privacy Policy page - COPPA-compliant with parental rights documentation
  3. Consent tracking in database - Timestamped proof of agreement
  4. UX integration - Clear notice without friction

Question 1: Should We Use a Paid Service?

First decision: DIY legal docs or pay for Termly/Iubenda?

My question: “Would it be best to use a paid service for terms and stuff or will this work?”

The answer: Start with custom for launch, upgrade to paid when you have paying customers.

This made sense. The templates I created used industry-standard COPPA language. For an MVP launch, it’s legally sufficient. When revenue starts flowing or we want extra legal protection, we can upgrade.

Lesson: Don’t over-optimize before validation. Get legally compliant now, professionally bulletproof later.

The Implementation Journey

I started by creating two comprehensive legal documents:

Terms of Service (/terms):

  • 14 sections covering everything from user eligibility to governing law
  • Clear 18+ parent/guardian requirement
  • Reference to COPPA compliance
  • Contact information for legal requests

Privacy Policy (/privacy):

  • Prominent COPPA compliance notice with amber warning styling
  • Detailed parental rights section (review, delete, modify data)
  • Data collection transparency
  • Security measures documentation
  • Third-party service disclosures

Both pages follow the same structure:

  • Professional header with “Back to Home” link
  • Dynamic “Last Updated” date
  • Clean, readable sections
  • Clear contact information
// Example from Privacy Policy - COPPA Compliance Notice
<section className="bg-amber-50 border border-amber-200 rounded-lg p-6">
  <h2 className="text-xl font-semibold text-amber-900 mb-3">
    ⚠️ COPPA Compliance Notice
  </h2>
  <p className="text-amber-900 leading-relaxed mb-2">
    This Service is intended for use by parents and legal guardians
    to track athletic performance of children under 13.
    We comply with the Children's Online Privacy Protection Act (COPPA) by:
  </p>
  <ul className="list-disc pl-6 text-amber-900 space-y-1">
    <li>Requiring verifiable parental consent before collecting children's information</li>
    <li>Collecting only information necessary to provide the Service</li>
    <li>Not requiring children to provide more information than necessary</li>
    <li>Providing parents with the ability to review, delete, and control their child's information</li>
    <li>Maintaining reasonable security procedures to protect collected information</li>
  </ul>
</section>

Step 2: Database Schema Updates (Where Things Got Interesting)

The plan was simple: add 5 fields to track legal consent:

model User {
  // ... existing fields ...

  // Legal compliance (COPPA)
  agreedToTerms        Boolean   @default(false)
  agreedToPrivacy      Boolean   @default(false)
  isParentGuardian     Boolean   @default(false)
  termsAgreedAt        DateTime?
  privacyAgreedAt      DateTime?
}

First Attempt: npx prisma db push

Error: ERROR: syntax error at or near ","
   0: sql_schema_connector::apply_migration::migration_step

Prisma couldn’t generate the SQL for the complex table alteration.

Second Attempt: npx prisma db push --accept-data-loss

Same error. Not a data loss issue - Prisma just couldn’t parse the schema changes.

Third Attempt: npx prisma migrate dev

Error: Database schema created with `prisma db push`,
not with migrations. Cannot create migration.

Here’s the problem: our development database was created with db push (quick prototyping), not migrations (production-ready). Prisma won’t let you mix the two approaches.

The Solution: Direct SQL

I bypassed Prisma entirely and went straight to PostgreSQL:

psql "$(grep DATABASE_URL .env.local | cut -d'=' -f2 | tr -d '"')" -c "
ALTER TABLE users
ADD COLUMN IF NOT EXISTS \"agreedToTerms\" BOOLEAN DEFAULT false,
ADD COLUMN IF NOT EXISTS \"agreedToPrivacy\" BOOLEAN DEFAULT false,
ADD COLUMN IF NOT EXISTS \"isParentGuardian\" BOOLEAN DEFAULT false,
ADD COLUMN IF NOT EXISTS \"termsAgreedAt\" TIMESTAMP,
ADD COLUMN IF NOT EXISTS \"privacyAgreedAt\" TIMESTAMP;
"

Result: ALTER TABLE (success!)

Then regenerated the Prisma client:

npx prisma generate

Why This Worked: Sometimes the tool is getting in the way. When Prisma’s migration system couldn’t handle the change, raw SQL could. This is production database management reality - you need to know multiple approaches.

Lesson: Know your database. Know SQL. Don’t be afraid to bypass your ORM when it’s failing you.

Step 3: UX Implementation - Simpler Than Expected

Based on my initial question about consent UX, we went with implicit consent:

Registration Form Changes:

  1. Added legal notice below “Create Account” button
  2. Made Terms/Privacy links open in new tabs
  3. No checkboxes required
{/* Submit Button */}
<Button type="submit" className="...">
  {isLoading ? 'Creating Account...' : 'Create Account'}
</Button>

{/* Legal Consent Notice */}
<p className="text-center text-xs text-zinc-500 leading-relaxed">
  By creating an account, you agree to our{' '}
  <Link href="/terms" target="_blank" className="text-zinc-900 underline hover:text-zinc-700">
    Terms of Service
  </Link>{' '}
  and{' '}
  <Link href="/privacy" target="_blank" className="text-zinc-900 underline hover:text-zinc-700">
    Privacy Policy
  </Link>
  , and certify that you are 18+ and the parent/legal guardian
  of any minors whose data you enter.
</p>

This approach:

  • ✅ Legally valid (affirmative consent via button click)
  • ✅ User-friendly (no extra clicks)
  • ✅ Transparent (links to full documents)
  • ✅ Accessible (opens in new tabs for review)

Step 4: Registration API Updates

The backend needed to automatically record consent when users register:

// src/app/api/auth/register/route.ts

// Create user in database with legal consent fields
const now = new Date();
const user = await prisma.user.create({
  data: {
    firstName,
    lastName,
    email,
    phone: phone || null,
    password: hashedPassword,

    // Legal compliance (COPPA) - set automatically on registration
    agreedToTerms: true,
    agreedToPrivacy: true,
    isParentGuardian: true,
    termsAgreedAt: now,
    privacyAgreedAt: now,
  },
});

Critical Detail: The timestamps. We’re not just tracking if they agreed - we’re tracking when. This creates an audit trail. If there’s ever a legal question about consent, we have proof with exact timestamps.

Added links to both legal documents in the landing page footer:

<div className="flex flex-col md:flex-row items-center gap-8">
  <Link href="/login" className="...">Sign In</Link>
  <Link href="/register" className="...">Get Started</Link>
  <Link href="/terms" className="...">Terms of Service</Link>
  <Link href="/privacy" className="...">Privacy Policy</Link>
</div>

Now users can access legal documents from anywhere in the app.

Production Deployment Question

Midway through implementation, I asked:

Me: “Is this a containerized app? Also when this is live do we have the cloud set up to save all this stuff?”

This revealed a crucial concern: is our infrastructure ready for production data?

The answer was comprehensive and reassuring:

Cloud Infrastructure Status (verified via gcloud CLI):

✅ Google Cloud Project: hustle-dev-202510
✅ Cloud SQL PostgreSQL: hustle-db (RUNNABLE, PostgreSQL 15)
✅ Cloud Run Service: hustle-app (DEPLOYED)
✅ VPC Connector: hustle-vpc-connector (READY)
✅ Private database connection (10.240.0.3)
✅ Automatic daily backups + point-in-time recovery

Containerization: Yes, Docker multi-stage build with Next.js standalone output.

Data Persistence: All user data goes to Cloud SQL, fully managed by Google Cloud with automatic backups.

This answered my unspoken question: “Is this production-ready?” Answer: Yes.

The GitHub Release Process

Once everything was working, I ran the /release command to execute the complete GitHub release pipeline:

What Happened:

  1. Version Bump: 0.1.0 → 0.0.1 (corrected to sequential versioning)
  2. Changelog Generation: 120-line comprehensive changelog entry
  3. Git Tag Creation: v00.00.01 with annotated release notes
  4. GitHub Release: Created with full documentation
  5. Artifact Archiving: Saved changelog, release notes, package.json, and version metadata
  6. Git Push: All commits and tags pushed to main branch

The release includes detailed metrics:

  • Legal Pages Created: 2
  • Database Fields Added: 5
  • Documentation Files: +4 comprehensive DevOps guides
  • Files Changed: 87
  • Lines Added: 12,943

What We Learned

It’s a complete system:

  • Legal documents (Terms, Privacy)
  • Database tracking (who agreed to what, when)
  • UX integration (clear, accessible)
  • Audit trails (timestamped consent)
  • Footer accessibility (easy to find)

2. ORMs Are Tools, Not Solutions

When prisma migrate failed, we didn’t give up on the feature - we went around the tool:

  • Tried db push (failed)
  • Tried migrate dev (incompatible)
  • Used direct SQL (success)
  • Regenerated Prisma client (integrated)

Lesson: Know your database. Know SQL. Be ready to bypass your ORM when needed.

3. UX Simplicity Can Be Legally Valid

We didn’t need checkboxes for consent. The act of clicking “Create Account” with visible legal language is legally sufficient. This makes for better UX and valid legal consent.

Key Requirement: The legal notice must be visible and the user must take an affirmative action (button click).

4. Ask Infrastructure Questions Early

My question about containerization and cloud setup came mid-implementation. It would have been better earlier. Fortunately, everything was already production-ready, but verifying infrastructure before implementing features is always smart.

5. Documentation Compounds Value

We created 4 comprehensive DevOps guides alongside the legal compliance work:

  • Deployment procedures
  • Architecture deep-dive
  • Operations guide
  • Competitive advantage analysis

These documents make future development faster and onboarding easier.

The Final State

What’s Live: https://hustle-app-zk63g3embq-uc.a.run.app

What Works:

  • ✅ COPPA-compliant Terms of Service
  • ✅ COPPA-compliant Privacy Policy
  • ✅ Automatic consent tracking in PostgreSQL
  • ✅ Timestamped audit trail
  • ✅ User-friendly registration flow
  • ✅ Footer links on all pages
  • ✅ Production-ready infrastructure verified
  • ✅ Automatic backups configured

What’s Next:

  • Custom domain setup (optional)
  • Email verification flow (production email service)
  • Payment processing (future feature)
  • Public launch announcement

Code References

If you found this journey interesting, check out these related posts:

Built with:

  • Next.js 15.5.4 + Turbopack
  • NextAuth v5
  • Prisma ORM + PostgreSQL
  • Google Cloud (Cloud Run, Cloud SQL, VPC)
  • shadcn/ui components

Production Infrastructure:

  • Containerized with Docker
  • Deployed to Google Cloud Run
  • PostgreSQL on Cloud SQL
  • Private VPC networking
  • Automatic daily backups + point-in-time recovery

This post documents real development work completed on October 8, 2025. All code is in production at Hustle.