Durante una fase de expansión es fácil medir el progreso contando: otro juego, otra categoría, otra página. El repositorio cambia deprisa y el resultado es visible. Pero llega un punto donde seguir sumando empieza a ocultar las diferencias entre las piezas.
La auditoría de PuzzleHub nació de esa sensación. No había un único bug enorme que resolver. Había muchas pequeñas decisiones que, vistas juntas, decían que la plataforma necesitaba consolidación.
La deuda que no aparece como bug
Un tablero puede funcionar perfectamente y seguir necesitando trabajo. Márgenes distintos, controles en lugares diferentes, explicaciones inconsistentes, estados de hover, modo claro incompleto o una página demasiado estrecha no siempre rompen tests, pero sí rompen la sensación de producto.
Este tipo de deuda es peligrosa porque cada elemento aislado parece pequeño. Con decenas de juegos, la suma deja de ser pequeña.
La ausencia de errores no es lo mismo que la presencia de calidad.
Primero arreglar la base
Hay muchas funciones nuevas que queremos construir, pero añadirlas sobre inconsistencias existentes aumenta el coste futuro. La prioridad se desplazó hacia componentes comunes, anchuras coherentes, espacio para tableros, temas completos, navegación y una estructura de catálogo capaz de crecer.
Es una inversión con efecto multiplicador: una buena decisión común beneficia también a lo que todavía no hemos construido.
Sudoku como referencia, no como plantilla
El rediseño de Sudoku nos dio un laboratorio concreto para definir color de categoría, controles, onboarding, explicaciones y jerarquía. La intención no es clonar su aspecto en todos los juegos, sino aprender qué patrones sobreviven al pasar a mecánicas distintas.
Eso nos permite auditar con una referencia más precisa que «hacerlo más bonito». Podemos preguntar si otro juego tiene la misma claridad de acciones, si explica igual de bien su objetivo o si el tablero recibe el protagonismo adecuado.
El ancho también es funcionalidad
Una de las mejoras más sencillas ilustra bien el proceso. El contenedor general era demasiado estrecho para algunos juegos. Eso podía hacer tableros grandes incómodos o incluso comprometer la jugabilidad.
Ampliar el espacio útil mejora presentación y juego a la vez. También nos recuerda que una regla de layout nacida en una página editorial no debe convertirse accidentalmente en una limitación para toda la plataforma.
Modo claro como detector de deuda
Soportar otro tema expone rápidamente colores hardcodeados, bordes dependientes del fondo y componentes que no tenían estados definidos. Por eso el trabajo de modo claro se integró en la auditoría general en lugar de tratarse como un acabado separado.
Lo mismo ocurre con responsive y accesibilidad: son pruebas que revelan cuánto depende una interfaz de supuestos no escritos.
Convertir la auditoría en tareas
Los hallazgos no deberían quedarse en un documento enorme que envejece. Los estamos transformando en tareas independientes y priorizadas en nuestro sistema de proyecto, con suficiente información para ejecutarlas una a una.
Esta forma de trabajar tiene otra ventaja con agentes de IA: una observación vaga como «mejorar la UI» es difícil de delegar y revisar; una tarea acotada con contexto, precedentes y criterio de terminado produce cambios mucho más controlables.
- separar síntomas de causas;
- priorizar por impacto y dependencia;
- convertir mejoras grandes en unidades verificables;
- registrar decisiones para no redescubrirlas;
- cerrar tareas solo cuando el resultado está realmente aplicado.
Auditar también significa decidir qué no hacer
Una lista de ideas puede crecer indefinidamente. La auditoría nos obliga a distinguir funciones atractivas de problemas que ya afectan a todos los usuarios. En esta fase, una mejora del sistema común puede valer más que otra feature aislada.
También estamos separando mejor los juegos competitivos de los puzzles individuales y revisando cómo se presentan más de setenta opciones. Son decisiones estructurales que tienen más retorno ahora que añadir otra tarjeta al catálogo.
Rendimiento de producto y rendimiento técnico
Queremos páginas rápidas, pero el concepto de rendimiento es más amplio. ¿Cuánto cuesta añadir un juego? ¿Cuánto tarda una mejora común en llegar a todos? ¿Cuántas excepciones necesita el sistema? Una arquitectura que obliga a repetir trabajo también es lenta, aunque Lighthouse marque buenos números.
La siguiente versión se construye sobre esta limpieza
Cuando la base visual, estructural y técnica sea consistente, cada nuevo juego heredará mejores decisiones por defecto. Ese es el rendimiento que buscamos: menos fricción para usuarios y menos fricción para desarrollar.
Probablemente volveremos a una fase de expansión. Pero queremos llegar a ella con una plataforma capaz de absorber nuevas piezas sin que cada incorporación aumente el caos.
Parar para auditar no fue dejar de construir PuzzleHub. Fue empezar a construir aquello que no se ve en una tarjeta nueva: la capacidad de seguir creciendo bien.