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 platform built completely inside Google AI Studio with the Gemini 3 Flash Preview model. It covers Parent, Coach, and Admin roles, Firestore real-time sync, and English-Spanish translation of every static string and every live message, so users do not have to leave the app to communicate across a language barrier.
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 routine in everyday life: anyone can pull out a phone and hold a conversation across a language barrier. Despite that, no prominent youth-sports registration platform implements translation inside the product, which forces parents, coaches, players, and administrators to use external tools to communicate with one another.
Youth Sports Platform addresses that gap by including built-in translation of all pages, text, and messages. 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 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.
| Tool | Approach | Weakness | Our edge |
|---|---|---|---|
| TeamSnap | Major youth-sports registration platform | No in-platform English-Spanish translation; users copy-paste into external tools | Built-in translation of all pages, text, and messages |
| LeagueApps | Major youth-sports registration platform | No in-platform English-Spanish translation; users copy-paste into external tools | Built-in translation of all pages, text, and messages |
| SportsEngine | Major youth-sports registration platform | No in-platform English-Spanish translation; users copy-paste into external tools | Built-in translation of all pages, text, and messages |
The core differentiator is built-in English-Spanish translation across the whole product. Static strings are handled by i18next; live, user-generated messages route through the Gemini API, so English-speakers and Spanish-speakers can communicate 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.
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 an error surfaced during preview. 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 supported rollback after a broken change (which happened once during the build), and a separate markdown context file was unnecessary since all prompting and code lived in the studio. The initial project-level prompt was generated with ChatGPT as a Gemini-tailored prompt.
Gemini set up user authentication and the entire Firebase 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. First, 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. Second, the model would add a trash-can icon to data entries without wiring the deletion behavior, requiring a follow-up prompt to actually implement deletion.
Firebase hosting and Gemini vibe-coding both ran on the free tiers of the underlying platforms, with no rate-limit issues encountered during development.
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.
- Vague prompts got vague outputs; specific prompts (for example, "in the Program Registrations tab of the admin console, once approved or rejected, those should no longer be in a pending state") landed the feature exactly as intended.
Vibe-coding shifts the work from writing code to managing the model. The developer never read Gemini's generated code and instead spent attention on deciding how the product should behave, then re-prompting until the behavior matched. Prompt specificity is the lever: more context and constraints in the prompt produce a closer first-pass output.
The evidence.
Limits & next.
Limits
- The product is positioned as a demo rather than a finished commercial platform; individual sport clubs would need a customized version to fit their specific needs.
- Designing and hosting a more complex platform would likely exceed the free tiers the product currently runs on, though rate-limiting was not hit during development.
- All code is Gemini-authored and was never directly inspected by the developer.
Next
- Stress-test the free-tier bounds (Firestore reads, Gemini calls) under realistic multi-club load, since rate-limiting was not hit during development.
- Use the current product as a base and re-vibe-code a customized fork for an interested club's specific workflow.