PokéVault: saber qué te falta y cuánto vale tu colección de cartas, sin hojas de cálculo
Ficha Técnica del Proyecto
Mes
Mes 3
Proyecto
PokéVault
Stack Tecnológico
Herramientas IA
Tengo cartas de Pokémon desde niño y, desde hace un par de años, he vuelto a comprar sobres y cartas sueltas en serio. El problema es el de siempre: una hoja de cálculo que dejo de actualizar a las dos semanas y ninguna forma rápida de saber qué me falta de un set sin repasar la carpeta carta a carta.
PokéVault es mi solución, el tercer proyecto del reto de 12 meses, 12 proyectos: sincronizo el set que me interesa, marco de golpe lo que ya tengo y sé en todo momento cuánto vale la colección, sumado carta a carta con un precio de referencia real.
El problema
Quien colecciona acaba con dos preguntas que no se contestan solas: qué me falta y cuánto vale lo que tengo. Para la primera hay que repasar el archivador carta a carta. Para la segunda se tira de una cifra a ojo, que no dice si has ganado o perdido con lo que compraste.
Una hoja de cálculo lo cubre un tiempo, pero hay que mantenerla a mano y se queda vieja enseguida. Y cuando la colección crece, cada set nuevo es otro rato de copiar cartas y precios.
La solución
PokéVault tiene cuatro pantallas: Mi colección, Plan, Wishlist y Resumen. Dentro de Mi colección hay tres pestañas: Sets, Cartas y Sellado.
Para cada set hay un checklist. Buscas el set en español o en inglés, lo eliges de una lista real de candidatos (nunca se adivina) y se descarga con el precio de referencia de Cardmarket carta a carta. Desde ahí puedes marcar varias cartas como tuyas de golpe, con la foto y el precio ya rellenados.

Si lo que te interesa es un Pokémon concreto, puedes crear un binder con todas sus cartas, de cualquier expansión donde haya salido, sin sincronizar cada set entero.

El Resumen da el valor total, lo invertido y la ganancia o pérdida estimada. Lo que todavía no tiene un valor conocido sale en un aviso aparte: nunca se cuenta como 0 € en silencio, que falsearía el total.

Es multiusuario: cada persona entra con su cuenta y solo ve sus datos. Al iniciar sesión hay una casilla «Recuérdame en este dispositivo», pensada para distinguir un dispositivo propio de uno compartido.
Qué demuestra este proyecto
- Un producto multiusuario de verdad: login obligatorio y cada dato ligado a su usuario, de modo que nadie puede leer o tocar los de otra cuenta adivinando un id. La migración se hizo en dos pasos para no romper los datos que ya existían.
- Evitar trabajo duplicado cuando varias personas usan lo mismo: el catálogo de un set se guarda una sola vez para todos los usuarios. Con dos usuarios sincronizando el mismo set de 99 cartas, el segundo tardó unos 20 ms frente a varios segundos del primero, y se guardaron 147 filas de cartas, no 294.
- Mostrar solo datos fiables: lo que no tiene valor conocido se avisa aparte en lugar de sumarse como cero.
- Probar con casos reales y corregir: un fallo con dos cartas reales de un mismo set salió al probarlo y quedó cubierto con tests.
- Saber quitar lo que no encaja: el reconocimiento de cartas por foto con IA funcionaba, pero solo en mi ordenador, y lo eliminé antes de preparar el despliegue para que la app se comportara igual en local y en producción.
El resultado técnico
Para quien quiera el detalle: React y TypeScript en el frontend, Node con Fastify en el backend y PostgreSQL, con arquitectura hexagonal. El catálogo de cartas viene de TCGdex. Estos son los fallos más ilustrativos:
- La misma carta aparecía como tuya en dos sitios a la vez. Un binder reúne un Pokémon de varias expansiones, y si una de ellas también estaba sincronizada como set oficial, marcar la carta en uno la marcaba en el otro (caso real: Slowbro y Slowpoke de «Oscuridad Absoluta»). Lo arreglé guardando a qué checklist pertenece cada ejemplar, con un test de dominio y un test de extremo a extremo.
- Las migraciones fallaban en producción por no encontrar la variable DATABASE_URL: el proyecto carga el .env con la API nativa de Node, pero la herramienta de migraciones no lo sabía.
- Un test fallaba la segunda vez que se ejecutaba la suite completa, por un usuario de prueba fijo que no se borraba entre ejecuciones.
- El despliegue automático apuntaba a una copia local desfasada en vez de a GitHub, resto de un método de despliegue anterior.
Antes de volver a publicar el repositorio audité todo el historial de commits en busca de claves o contraseñas reales: no había ninguna, pero había que comprobarlo. También resolví 9 vulnerabilidades de dependencias (2 altas) sin cambios de comportamiento.
En su momento decidí no desplegar una demo en vivo, porque mostraría cuánto pagué por cada carta y cuánto vale la colección entera, y esa cifra no quiero colgarla en internet con mi nombre al lado. Al publicar este artículo, el repositorio volvió a ser público, con capturas hechas con datos de demostración.
Ver el repositorio de PokéVault en GitHub
Si necesitas algo parecido, una herramienta con cuentas de usuario en la que cada persona ve solo sus datos, cuéntame qué tienes en mente.