Group X · Civic tools · CSCI 455 / 555 · Spring 2026

Youth Sports Platform

A vibe-coded full-stack registration platform for youth sports clubs with built-in English/Spanish translation across every page, string, and live message.

Nearly 45 million Americans speak Spanish at home, yet no major youth-sports registration platform ships in-platform translation. Youth Sports Platform is a full-stack Software-as-a-Service demo built end-to-end inside Google AI Studio with Gemini 3 Flash Preview. It covers parent / coach / admin roles, real-time Firestore data, and automatic English-Spanish translation of every static string and every live message — so parents and clubs never have to leave the app to communicate across a language barrier.

React 18 + ViteTailwind CSSFirebase FirestoreFirebase Authi18nextGemini API

The brief.

According to census.gov, nearly 45 million Americans speak Spanish at home. Tools like Google Translate and Apple's Live Translation make real-time cross-language communication trivial in everyday life — anyone can pull out a phone and have a conversation across a language barrier. Despite that ease of access, none of the prominent youth-sports registration platforms implement translation inside the product. Parents, coaches, players, and administrators are pushed out to external tools to communicate with one another.

Youth Sports Platform fixes that by making translation a first-class feature of the registration product, not an afterthought. Every page, every static UI string, and every live message routes through translation so a Spanish-speaking parent and an English-speaking coach can register, schedule, and message without ever copy-pasting into a separate translator. The product was built entirely inside Google AI Studio with the Gemini 3 Flash Preview model.

Target: Youth sports club administrators looking for an easy-to-use full-stack SaaS platform that ships with bilingual support out of the box.

None of the major youth sport registration platforms (TeamSnap, LeagueApps, SportsEngine) support in-platform English-Spanish translation, requiring users to copy-paste text into other translation tools.From the write-up

The landscape.

ToolApproachWeaknessOur edge
TeamSnapEstablished youth-sports registration and roster managementNo in-platform translation; users copy-paste into external tools to bridge English-Spanish messagingTranslation is wired through every page, static string, and live message by default
LeagueAppsLeague management and registration for clubs and organizationsEnglish-first UI with no bilingual support for parents on the other side of a language barrieri18next-backed static translations plus Gemini-routed live message translation
SportsEngineEnd-to-end club operations platformDoes not address the bilingual communication need between coaches/admins and Spanish-speaking familiesFree demo running on Firebase + Gemini free tiers — vibe-codeable by any club

The core differentiator is that translation is not a feature bolted onto a registration product — it is the product's reason to exist. Every static label is keyed through i18next with en.json and es.json bundles; every live, user-generated message routes through the Gemini API so that English-speakers and Spanish-speakers can hold a real conversation inside the app without an external translator.

The system.

The platform follows a Full-Stack Serverless (FSS) architecture pattern, optimized for high reactivity and low maintenance. Firebase handles authentication, Firestore stores the data, and the React 18 + Vite + Tailwind front-end renders the user interface. Motion for React provides animations. i18next ships the static-string translation layer, and the Gemini API handles real-time translation for messages and other dynamic content.

Data is structured as separate Firestore collections for programs, registrations, players, teams, and events. Components use onSnapshot listeners so that when an admin approves a registration in RegistrationManager.tsx, the ParentDashboard updates its local state globally and instantly via a centralized App.tsx state / Context provider. Role-based access control is managed in AuthContext.tsx: users are assigned a Parent, Coach, or Admin role stored in a profiles collection linked to their Firebase Auth UID, and firestore.rules enforce the rules at the database level (so, for example, a Parent cannot edit programs but can update their own players).

A recursive DashboardLayout provides a consistent navigation shell while dynamically rendering ScheduleView, AdminDashboard, ParentTeamsView, and similar views based on active state and user permissions.

Youth Sports Platform home dashboard greeting Destiny with left-nav, registration count cards, an approved Recreational Soccer registration, and a Tuesday Practice schedule card.
Figure 1 · Home dashboard · Parent landing view with registrations, programs, and schedule cards.

The implementation.

The entire platform was built inside Google AI Studio with the Gemini 3 Flash Preview Model. The vibe-coding workflow was: write a feature request in natural language, let Gemini implement (and, when necessary, rebuild) the app, review the change in the in-studio Preview tab, and use the auto-detected error "fix" button when something broke. If a feature landed wrong, a follow-up prompt described the issue in plain English ("the button does not do anything") and Gemini iterated. AI Studio's checkpointing made rollback safe; a separate markdown context file was unnecessary since all prompting and code lived in the studio.

Gemini set up Firebase authentication and the entire backend with no manual work on the developer's end. Most features worked after the first pass; secondary prompting was usually only needed to add edit/delete affordances for created data entries. Two recurring issues showed up: (1) Gemini would forget that new features also needed translation until prompted that EVERY string in the platform needs to be translatable, after which it added translation hooks without further reminders; (2) useless UI — the model would add a trash-can icon to data entries without wiring the deletion behavior, requiring a follow-up prompt to make the icon do its job.

The full project — Firebase hosting and Gemini vibe-coding — ran on free tiers of the underlying platforms with no rate-limit issues encountered during development.

Google AI Studio with Gemini chat history listing localization changes on the left and a live preview of the bilingual Youth Sports Platform landing screen on the right.
Figure 2 · Google AI Studio · Chat-driven feature requests on the left, live app preview on the right.

Built with AI.

Where AI helped

  • Gemini stood up the entire Firebase backend and user authentication with no manual code on the developer's side.
  • Most feature requests landed correctly on the first pass; secondary prompts were only needed to add edit/delete affordances.
  • The model produced useful summaries of which files it touched and the rationale for each change.

Where AI struggled

  • Early in the project, Gemini forgot that new features also needed to participate in translation until told explicitly that EVERY string must be translatable.
  • Generated UI affordances were sometimes cosmetic — a trash-can icon appeared on data entries but did not actually wire up deletion until a follow-up prompt.
  • Initial prompts that lacked specificity got vague outputs; concrete prompts ("in the Program Registrations tab of the admin console, once approved or rejected, those should no longer be in a pending state") got pixel-accurate results.

Vibe-coding shifts the work from writing code to managing the model. The developer never read Gemini's generated code; the attention budget went entirely to deciding how the product should behave and then re-prompting until the behavior matched. Prompt specificity is the lever — the more context and constraints the prompt carries, the closer the first-pass output lands.

The evidence.

Limits & next.

Limits

  • The product is positioned as a demo / template rather than a turnkey commercial platform — individual sport clubs would need a customized fork to fit their workflows.
  • Free-tier hosting and Gemini API caps would likely need to be upgraded for a more complex, multi-club deployment.
  • All code is Gemini-authored and was never directly inspected by the developer, so deep customization beyond prompt-driven changes is an open question.
  • Translation quality depends on Gemini's real-time output for live messages; no human-review layer is in place.

Next

  • Stress-test the free-tier bounds (Firestore reads, Gemini calls) under a realistic multi-club load.
  • Add languages beyond English and Spanish using the same i18next + Gemini routing pattern.
  • Introduce a thin moderation / review layer over translated live messages for sensitive admin-to-parent communications.
  • Bundle the prompts.pdf playbook into a reusable starter so any club can re-vibe-code a customized fork.