Un club atado al software
de un proveedor.

Racing no tenía un sistema de socios. Lo alquilaba. BoleteríaVip manejaba pagos, ticketing, control de accesos y datos de socios — y Racing no podía tocar nada. Sin exports. Sin API. Sin forma de conectar los datos de socios con nada más que el club necesitara.

Cuando conocimos a Racing en 2017, los ayudamos a lanzar su primera app oficial. Se dio de baja, pero la relación quedó. Cuando volvimos a hablar, les propusimos retomar la app. Racing vino con un pedido más grande: matar al proveedor, construir la plataforma, ser dueños de los datos.

Esa decisión — construir, no comprar — es lo que hizo posible todo lo demás.

El desafío técnico era real, pero no era lo difícil. Lo difícil era el tiempo.

La negociación se comió la mitad del proyecto. Un plan de 12 meses se comprimió a 6. Tuvimos 2–3 meses de relevamiento solo para mapear cómo funcionaba el sistema anterior — y la mayor parte vivía en la cabeza de la gente, no en documentos. El equipo de socios cargaba las reglas de negocio en memoria muscular. Estado de cuotas. Categorías. Lógica de débito automático. Nadie lo había documentado porque simplemente funcionaba.

Y el alcance era enorme: socios, pagos, ticketing, control de accesos, reportería — con 14 categorías de socio, descuentos por grupos familiares, múltiples procesadores de tarjetas, butacas numeradas y no numeradas, molinetes con RFID, y +30 personas entre los departamentos de Racing.

Teníamos dos opciones. Construir todo lo que la analista funcional había documentado — 1.342 párrafos de lógica institucional — y salir en 18 meses. O simplificar cada problema en algo publicable, perder detalle, y escalar después del lanzamiento. Elegimos lo segundo.

Eso significó cortar alcance sin piedad. Dos frontends separados en lugar de una mega-app. Débito automático marcado como menor — hasta que se convirtió en la feature más crítica. Selección de butacas 3D fuera de la fase 1. Factura electrónica postergada. Cada corte fue una decisión: cedimos completitud por la posibilidad de salir a producción.

Fue la decisión que salvó el proyecto — y la que más refinaríamos con el tiempo.

La fecha límite era diciembre 2022. Después enero. Después febrero. Y entonces se quemó el hardware del sistema anterior — literalmente — y Racing tuvo que salir a producción con lo que tuviera listo.

No debería haber funcionado. Lo probamos en la cancha durante el primer partido, refinando las queries de control de accesos entre tiempos. En el segundo partido, las queries ya respondían rápido. En el tercero, los socios pasaban por los molinetes sin incidentes. La migración de datos corría de noche: exportábamos del sistema viejo al cierre y cargábamos al nuevo antes de la mañana.

La parte más cruda fue el registro de socios — lo primero que un socio nuevo toca. Fue lo último que queríamos publicar sin terminar. Pero lo hicimos, y lo arreglamos en vivo.

Elegimos serverless-first en AWS porque el equipo necesitaba publicar módulos nuevos constantemente — pagos un mes, control de accesos el siguiente, features de IA un año después. Una infraestructura fija habría sido un cuello de botella en cada iteración. Costo variable significaba pagar por partidos y renovaciones, no por servers idle. Bajo DevOps significaba que una sola persona podía correr todo.

Una sola Aurora RDS MySQL en todos los módulos mantuvo la integración simple. La arquitectura absorbió picos de tráfico por partidos, venta de entradas y renovaciones — llegamos al límite y fuimos puliendo el setting de la DB con meses de carga real.

Si lo hiciéramos hoy, el frontend lo haríamos en Next.js sobre Vercel. Las decisiones de backend envejecieron bien.

Antes: un proveedor era dueño de los datos, los canales y el roadmap. Racing no podía conectar su sistema de socios con nada — ni la app, ni la web, ni el software de contabilidad.

Después: Racing es dueño de todo. Los socios se autogestionan desde la webapp y la app oficial. Los equipos internos corren cada operación desde un solo backoffice — débito automático, reportería, facturación, ticketing, control de accesos. El club decide qué conectar y cuándo. Sin dependencia de proveedores.

La plataforma corre socios, ticketing, accesos al estadio, colonias, deportes, rental de canchas, estacionamientos y administración. Sigue en producción. Sigue creciendo.

Habríamos presionado más fuerte en el timeline de la negociación. El relevamiento se comió la mitad del proyecto. La próxima vez, correríamos discovery y desarrollo en paralelo desde la semana uno — publicar las partes conocidas mientras seguimos mapeando las desconocidas.

También habríamos lanzado el registro de socios antes. Fue la parte más cruda del lanzamiento accidental, y era lo primero que un socio nuevo tocaba. Eso nunca debió ser el eslabón más débil.

Después del segundo partido, alrededor del 14–17 de febrero de 2023. Los molinetes funcionaban. Las queries respondían rápido. Los socios entraban. Nadie se quejó.

Racing valoró la confianza y la flexibilidad por sobre todo. El proyecto se destacó por el desafío, la falta de tiempo y la escala. PATMOS aprendió escalabilidad y velocidad de equipo para proyectos críticos — y redefinió todo: producto, arquitectura y operación.