El proyecto
Un fantasy del Mundial 2026 que armamos entre dos, de cero a producción en cinco días, y que terminó con cientos de personas jugándolo todas las fechas.
- Qué es
- Fantasy football del Mundial FIFA 2026
- Equipo
- 2 personas, sin inversión
- Cuándo
- Junio – julio 2026
- Rol
- Producto, diseño, backend, scoring, pagos y soporte
- Estado
- Cerrado tras la final · el sitio queda navegable
Los 11 de Sampa fue un juego de fantasy football del Mundial FIFA 2026. Armabas un equipo de 15 jugadores más un técnico dentro de un presupuesto, y cada fecha sumabas puntos según lo que esos jugadores hacían de verdad en la cancha: goles, asistencias, valla invicta, tarjetas, figura del partido. Competías en un ranking global y en ligas privadas con tus amigos.
Se nos ocurrió el 6 de junio de 2026, cinco días antes de que arrancara el Mundial, y en principio era para jugar entre nosotros y nuestro grupo de amigos. Salió a producción a tiempo para la primera fecha, y de ahí empezó a crecer solo: la gente creaba ligas y sumaba a sus conocidos. Cuando vimos que se había ido bastante más allá de los amigos, decidimos tomárnoslo en serio.
Lo hicimos dos personas, sin equipo detrás y sin inversión: producto, diseño, backend, scoring, pagos, legales, soporte y las redes. Funcionó las 8 fechas, hasta la final.
El Mundial terminó, así que el juego ya no está activo — pero el sitio quedó abierto: podés probar el armador sin crear cuenta, ver el ranking final real y recorrer todo lo que se construyó.
Medidos sobre la base de producción al cierre del torneo. El motor del crecimiento fueron las ligas privadas: alguien armaba una y sumaba a sus amigos.
Se nos ocurrió el 6 de junio; el Mundial arrancaba el 11
573 llegaron a armar equipo (85%)
402 usuarios (59%) entraron en al menos una
Un promedio de 2.3 por equipo a lo largo del torneo
8 fechas publicadas sobre 1.270 jugadores de 48 selecciones
276 pines gastados en cambios extra
- 700M de presupuesto para 11 titulares, 4 suplentes y un técnico. Los precios salen de los valores de mercado reales de Transfermarkt.
- Máximo 3 jugadores por selección en fase de grupos, 5 desde los 16vos (con menos selecciones vivas, si no no se podía armar equipo).
- Un capitán que duplica su puntaje base, y auto-sustitución: si un titular no juega, entra automáticamente el suplente de su posición que sí jugó.
- Un cambio gratis por fecha; los extra se pagaban con pines. Ligas privadas con su propio ranking, para competir entre amigos.
- Front + back
- Next.js 16 (App Router, Server Actions) · React 19 · TypeScript
- Base de datos
- Neon Postgres (serverless, HTTP) · Drizzle ORM + migraciones
- Auth
- Clerk (Google OAuth + email), con gate propio de nickname único
- Pagos
- Mercado Pago Checkout Pro + webhook · adapter de dLocal Go para LatAm
- Datos del Mundial
- API-Football (plan pago) · valores de mercado de Transfermarkt
- UI
- Tailwind v4 · shadcn/ui · design system editorial propio (Panini + Gran DT)
- Infra
- Vercel con auto-deploy desde main · placas de Instagram generadas por script
- API-Football
- syncRound()
- playerMatchStats
- publishRound()
- playerRoundPoints
- ranking
Después de cada jornada, un admin sincroniza las estadísticas de los partidos, revisa los casos raros a mano y recién ahí publica la fecha. Publicar recalcula el puntaje de todos los equipos, aplica la auto-sustitución y actualiza el ranking.
Publicar una fecha es irreversible, así que se trata como tal
Publicar reescribe los puntos de cientos de equipos. El botón vive detrás de un diálogo que te obliga a tipear la frase completa, exige que las fechas anteriores estén publicadas, y todo queda en un log de admin. Existe un despublicar, pero como red de emergencia, no como parte del flujo.
Atomicidad sin transacciones
Neon por HTTP no tiene transacciones clásicas. Guardar una alineación toca cuatro tablas y descuenta pines: si se rompe a la mitad, alguien pierde pines sin equipo. Todo eso se escribe con un solo db.batch(), que el server corre como una única transacción.
El cliente no decide nada que valga plata o puntos
Presupuesto, tope por país, cantidad de cambios y costo en pines se recalculan enteros en el server contra la base, ignorando lo que mande el navegador. Los pagos no se confirman desde el retorno del checkout sino desde el webhook del proveedor, verificado contra su API y con acreditación idempotente.
El saldo de pines es un ledger, no un número
No hay una columna balance: el saldo es la suma de un libro de movimientos con su motivo (compra, cambio, reembolso, regalo). Cuesta un poco más de query y hace que cualquier discrepancia se pueda auditar movimiento por movimiento, que es exactamente lo que necesitás cuando alguien te escribe diciendo que le faltan pines.
- Cerró en déficit: alrededor de $55.000 ARS entre infraestructura, la API de datos y marketing, contra los ingresos por pines. Nunca fue el objetivo ganar plata, pero el modelo no se sostenía solo.
- El scoring se sincroniza y se publica a mano desde el panel de admin. Con un cron y alertas, las fechas se habrían publicado horas antes y sin que alguien tuviera que estar mirando.
- Se nos ocurrió cinco días antes del Mundial, y ese fue el techo de todo: salimos con lo justo, sin tiempo de probar nada ni de conseguir usuarios antes del primer partido. Es lo que más nos quedó picando: con un mes de anticipación, el mismo producto habría llegado a muchísima más gente.
- La distribución dependió de que los usuarios armaran ligas con sus amigos. Funcionó, pero recién cuando ya había torneo en marcha: el momento de conseguir usuarios era antes del primer partido, no después.
El repo es público e incluye la documentación con la que trabajamos: la especificación del juego y su tabla de puntaje, el handoff técnico completo, el runbook de producción y la dirección de diseño.