Rugby Staff
Gestión para clubes de rugby amateur, con un servidor MCP que deja preguntarle al sistema en castellano.
- Next.js 16
- React 19
- Supabase
- RLS
- MCP
- OAuth 2.1
El problema
Un club de rugby amateur se maneja con planillas de Excel, tres grupos de WhatsApp y la memoria del entrenador. Funciona hasta que el entrenador se va.
Cuando eso pasa, el club pierde años de trabajo de golpe: quién vino a entrenar, qué testeos se hicieron, quién estuvo lesionado y cuánto tardó en volver, por qué tal jugador dejó de aparecer. Nadie lo anotó en un lugar que sobreviva a la persona.
La federación tiene su propia app, gratuita y de uso obligatorio, pero resuelve otra cosa: el día de partido y el cumplimiento federativo. La semana de trabajo del club sigue sin dueño.
Qué construí
Empecé por la semana, no por el partido: plantel, asistencia a entrenamientos, convocatorias, testeos físicos y lesiones. Todo pensado para que lo cargue un dirigente voluntario un martes a la noche, no un administrador dedicado.
Cada club ve solo lo suyo, y eso está garantizado en la base de datos con políticas de fila, no en el código de la aplicación. En un sistema con datos de menores esa diferencia no es un detalle de arquitectura.
La parte que más me interesa vino después: en lugar de construir una pantalla de reportes para cada pregunta posible, expuse los datos del club como un servidor MCP.
Dónde está hoy
El producto está en piloto con la M16 del Jockey Club de Rosario.
Todavía no hay números de resultado publicables: el piloto está corriendo y prefiero no inventar métricas antes de tenerlas.
Decisiones técnicas
Lo que no era obvio, y por qué terminó siendo así.
El MCP en vez de un tablero de reportes
El producto expone un endpoint MCP read-only con 23 herramientas sobre los datos del club: plantel, asistencia, convocatorias, estadísticas, testeos, lesiones. Con OAuth 2.1, conectable desde Claude o ChatGPT.
El efecto práctico es que un entrenador pregunta «¿quiénes faltaron a más de tres entrenamientos este mes en M16?» y lo obtiene, sin que exista una pantalla para esa pregunta. Cada reporte que no escribí es un reporte que no tengo que mantener.
Read-only fue deliberado: el modelo consulta el estado del club, no lo modifica. Escribir sigue pasando por la aplicación, donde están las validaciones.
CSS propio en lugar de Tailwind
El producto no usa Tailwind: tiene un sistema de átomos CSS propio. Es la decisión que más me discutirían y la mantengo, porque la aplicación tiene pocas pantallas y muchas repeticiones de las mismas piezas.
Este portfolio sí usa Tailwind. La herramienta la elige el problema, no la costumbre.
Lo que falta
El dominio propio. Mientras el producto viva en un subdominio prestado, todo el trabajo de posicionamiento queda a medias.