Medir antes de añadir otra capa
Cuando este artículo apareció por primera vez, el proyecto todavía se llamaba Blupoli. Hoy hablamos de Blupoli Puzzles, pero la etapa que describe sigue siendo una de las más importantes para entender cómo cambió nuestra forma de trabajar. Durante una fase de expansión, medir progreso es sencillo: aparece un juego nuevo, una categoría crece, una función entra en producción, una pantalla tiene más capacidades. Cada cambio es visible y produce una sensación inmediata de avance. La dificultad empieza cuando esa velocidad oculta una pregunta más incómoda: ¿todo lo que hemos construido sigue formando un producto coherente?
La auditoría nació porque la respuesta dejó de ser evidente. No había un gran incendio. No existía un único bug capaz de explicar la sensación de deuda. Había algo más peligroso: muchas decisiones razonables tomadas por separado que, vistas juntas, empezaban a producir fricción. Un tablero tenía menos espacio que otro. Un control cambiaba de lugar. El modo claro funcionaba mejor en unas superficies. Una explicación se entendía, otra daba por supuesto demasiado. El catálogo crecía y la forma de descubrir contenido seguía pareciéndose a la de una colección pequeña.
Ese tipo de deuda no suele activar una alarma automática. El código compila. Los tests pasan. La persona puede terminar una partida. Y, sin embargo, el producto se siente menos cuidado de lo que debería. Auditar fue nuestra forma de transformar esa sensación difusa en un mapa de trabajo.
La ausencia de bugs no es la presencia de calidad
Un equipo puede tener un backlog corto de errores y seguir acumulando deuda de producto. La razón es sencilla: muchas fricciones no son fallos binarios. Un botón demasiado lejos no está «roto». Un onboarding superficial no devuelve una excepción. Un ancho incómodo en tablet no bloquea siempre la partida. Una categoría poco clara no genera un crash. Sin embargo, todos esos detalles influyen en cuánto esfuerzo necesita alguien para usar el producto.
Esta diferencia obliga a ampliar el concepto de calidad. No basta con validar reglas o evitar errores técnicos. Hay que revisar comprensión, ritmo, accesibilidad, consistencia, descubrimiento, rendimiento percibido y capacidad de mantenimiento. Una plataforma de puzzles añade otra capa: el tablero puede ser correcto matemáticamente y aun así resultar poco agradable si la dificultad no está calibrada, el generador tarda demasiado o la interfaz no explica la primera jugada.
La auditoría se convirtió en un espacio donde esas cosas podían entrar en la misma conversación. No porque todas fueran igual de importantes, sino porque necesitábamos ver dependencias. A veces una pequeña mejora de sistema resolvía problemas en muchas páginas. Otras veces una aparente inconsistencia visual revelaba una frontera arquitectónica mal colocada.
Parar la expansión no significa que todo el trabajo nuevo sea malo
Una pausa de consolidación puede interpretarse como una reacción negativa al crecimiento: «hemos añadido demasiado, ahora hay que arreglarlo». Nuestra lectura fue distinta. La expansión había cumplido una función. Construir mecánicas diferentes nos enseñó qué necesitaba la plataforma. Aumentar el catálogo hizo visibles los límites de la navegación. Añadir temas reveló estilos acoplados. Probar motores heterogéneos mostró qué partes del shell eran realmente compartidas.
El problema no era haber experimentado. El problema habría sido continuar usando las mismas métricas después de que el contexto hubiera cambiado. Una etapa temprana puede optimizar aprendizaje y cobertura. Una etapa posterior necesita consolidar esas lecciones. Tratar ambas fases con la misma prioridad produce deuda.
Por eso la pausa fue deliberada. Antes de incorporar otra gran capa de funcionalidad queríamos elevar el suelo del producto: reducir excepciones, hacer consistentes las decisiones repetidas y convertir aprendizajes en infraestructura.
Una auditoría útil necesita mirar varias capas a la vez
Revisar solo la UI habría sido insuficiente. Muchas inconsistencias visuales venían de datos, motores o build. Revisar solo arquitectura tampoco habría capturado fricción real. Terminamos organizando el análisis alrededor de varias dimensiones: experiencia de uso, interfaz, rendimiento, arquitectura, contenido, descubrimiento y capacidad de escala.
En UX preguntábamos si la persona entendía qué hacer y si las acciones frecuentes estaban donde esperaba. En UI revisábamos jerarquía, estados, temas, espaciado y responsive. En arquitectura buscábamos duplicación, acoplamiento y excepciones que dificultaban mejorar todo a la vez. En rendimiento importaban tanto el tiempo de carga como los generadores que podían bloquear el navegador. En contenido mirábamos reglas, categorías, textos y rutas. En escalabilidad preguntábamos cuánto costaría repetir una mejora dentro de seis meses.
La utilidad de esta vista transversal estaba en encontrar causas comunes. Cinco síntomas en cinco juegos podían venir de una misma decisión compartida. Arreglar la causa tenía mucho más retorno que cerrar cinco tickets aislados.
El laboratorio de Sudoku nos dio una referencia concreta
Auditar sin referencia puede degenerar en una lista de gustos. «Esto debería verse mejor» o «aquí falta aire» son observaciones válidas, pero difíciles de priorizar si no sabemos qué experiencia queremos conseguir. El trabajo previo sobre Sudoku nos dio un caso donde habíamos cuidado jerarquía, controles, onboarding, feedback y estados con más profundidad.
No usamos Sudoku como plantilla visual. Lo usamos como contraste. Si una acción frecuente estaba cerca del tablero allí, podíamos preguntar por qué en otro juego estaba lejos. Si el foco era visible, podíamos detectar ausencias. Si el layout daba protagonismo al área interactiva, podíamos revisar páginas que todavía heredaban un ancho pensado para lectura.
La metodología está explicada con detalle en el artículo sobre Sudoku como laboratorio de diseño. La lección para la auditoría era simple: una referencia útil no prescribe píxeles; hace visibles principios.
El sistema compartido multiplicaba el retorno de cada hallazgo
La auditoría coincidió con la consolidación del sistema de UI común. Esa coincidencia cambió la economía del trabajo. Un problema en un componente compartido podía corregirse una vez y mejorar muchas experiencias. Una inconsistencia local, en cambio, nos obligaba a decidir si debía seguir siendo local o si revelaba una abstracción incompleta.
Esta diferencia nos hizo priorizar problemas de base antes que acabados aislados. Mejorar foco, temas, ancho, shell o estados comunes suele tener un efecto mayor que perfeccionar una sola pantalla. No porque los detalles individuales no importen, sino porque el sistema puede convertir una mejora en una capacidad heredada.
La auditoría empezó a medir «apalancamiento» además de gravedad. Un problema pequeño en una capa compartida puede merecer más atención que un defecto más visible en una pantalla poco usada si la corrección eleva el estándar de todo lo que viene después.
El ancho de la página fue un ejemplo pequeño con una lección grande
Algunos tableros sufrían dentro de un contenedor demasiado estrecho. La decisión original tenía sentido para contenido de lectura, pero había terminado propagándose a páginas cuyo elemento principal era interactivo. El resultado no era un bug universal: algunos juegos cabían bien; otros perdían espacio o escala.
Corregirlo exigía reconocer que «un layout común» no significa «una anchura idéntica». La plataforma necesitaba varios contextos de presentación. Este ajuste parecía puramente visual y terminó confirmando una idea de arquitectura: una regla compartida debe representar una responsabilidad real, no un accidente histórico.
Ese tipo de hallazgo es exactamente lo que hace valiosa una auditoría. La observación inicial puede ser «el tablero se ve pequeño». La causa puede ser «estamos reutilizando una restricción de contenido en un contexto de juego». La tarea correcta no es agrandar una página; es separar dos necesidades.
El modo claro funcionó como detector de estilos acoplados
Añadir un segundo tema expuso valores que parecían inocentes cuando solo existía un fondo oscuro. Bordes, sombras, colores de selección y estados deshabilitados dependían a veces de combinaciones concretas. La auditoría de tema obligó a distinguir colores semánticos de valores visuales y a revisar si los componentes realmente compartían una base.
La lección fue útil porque el modo claro dejó de ser una preferencia aislada. Se convirtió en una prueba de arquitectura. Si cambiar de tema exige excepciones por juego, algo está demasiado acoplado. Si un estado pierde significado cuando cambia el fondo, la semántica todavía depende de la apariencia.
Estas pruebas son valiosas porque revelan deuda antes de que llegue otra necesidad. Una interfaz preparada para más de un tema suele estar también mejor preparada para cambios de marca, accesibilidad y nuevas superficies.
Responsive y accesibilidad dejan menos espacio para las suposiciones
Una pantalla ancha y un ratón perdonan muchas decisiones. El móvil y el teclado no. Objetivos táctiles pequeños, contenido que desborda, controles que solo aparecen con hover, orden de foco extraño o estados comunicados únicamente por color se vuelven evidentes cuando cambiamos el modo de interacción.
Por eso la auditoría incluía viewport y métodos de entrada. No queríamos considerar responsive y accesibilidad como columnas al final de una checklist. Son maneras de someter el sistema a condiciones donde las suposiciones implícitas fallan.
Esta presión también resultó relevante para la estrategia Android. Como contamos en el artículo sobre Capacitor, reutilizar la web para una futura app solo tiene sentido si la web móvil es sólida. Auditar tacto, layout y persistencia mejoraba el producto actual y preparaba cualquier cliente posterior.
Rendimiento también significa coste de cambio
Cuando hablamos de rendimiento solemos pensar en carga, CPU y tiempo de respuesta. La auditoría añadió otra dimensión: ¿cuánto cuesta cambiar el producto? Una arquitectura donde una mejora común requiere editar docenas de páginas es lenta, aunque Lighthouse sea excelente. Una taxonomía duplicada en varios archivos ralentiza cada decisión. Un control con estilos distintos en muchos motores aumenta el riesgo de regresión.
Este «rendimiento de desarrollo» no sustituye al rendimiento técnico; lo complementa. La plataforma debe cargar rápido y también permitir que una mejora se propague con seguridad. Las dos cosas afectan la velocidad con la que podemos elevar calidad.
La auditoría buscaba especialmente lugares donde una tarea repetida podía convertirse en dato, componente o build. Cada repetición eliminada reduce tiempo y, sobre todo, divergencia.
Los generadores demostraron que correcto no significa suficiente
Parte de la deuda más importante estaba dentro de los juegos. Un generador puede producir un tablero válido y seguir ofreciendo una mala experiencia. Puede tardar demasiado, crear múltiples soluciones, repetir estructuras triviales o confundir tamaño con dificultad. Estas cosas no siempre se ven al abrir una partida.
Por eso la auditoría técnica necesitaba mirar más allá de la interfaz. Solvers, solución única, seeds, límites de tiempo y medición de dificultad forman parte de la calidad de producto. El trabajo desarrollado en «Generar un puzzle no es resolverlo» explica esa frontera con detalle.
La conexión con la auditoría es importante: mejorar la tarjeta de un juego sin revisar la calidad de las partidas habría sido cosmético. Consolidar significa comprobar la cadena completa, desde cómo se descubre un título hasta si el reto que genera merece el tiempo del jugador.
El catálogo necesitaba dejar de comportarse como una lista
A medida que crece la variedad, una página con tarjetas deja de ser suficiente para descubrir. La persona puede conocer «Sudoku» y buscarlo por nombre; otra puede querer «algo de deducción» sin saber qué título elegir. Categorías, filtros, búsqueda y contexto empiezan a ser parte del producto.
La auditoría nos obligó a preguntarnos si la información del catálogo ayudaba a tomar decisiones. ¿Las categorías describían realmente mecánicas? ¿Los textos daban contexto? ¿Las tarjetas anticipaban algo útil? ¿La jerarquía permitía explorar sin scroll infinito? ¿Los juegos competitivos debían compartir el mismo espacio que los puzzles de solución?
Estas preguntas no se resuelven añadiendo otra función aislada. Exigen revisar taxonomía, datos y navegación como un sistema. De nuevo, parar la expansión permitió trabajar en una capa que mejora el valor de todas las piezas existentes.
Una auditoría no sirve si termina en un documento enorme
Es fácil producir un informe excelente y no cambiar nada. Para evitarlo, cada hallazgo debía transformarse en trabajo ejecutable: una tarea con contexto, impacto, dependencia y criterio de terminado. Esa traducción obliga a ser más preciso. «Mejorar la UI» no es una tarea. «Separar el ancho editorial del ancho del game shell y verificar tableros grandes en móvil» sí puede serlo.
La granularidad también importa cuando parte del trabajo puede delegarse a agentes. Una instrucción vaga produce cambios difíciles de revisar. Una tarea que explica el problema, los archivos afectados, la intención y la validación permite más autonomía sin perder control.
La auditoría se convierte así en un sistema de decisiones, no en una fotografía. Observar, priorizar, convertir, ejecutar, verificar y cerrar. Cada paso reduce la posibilidad de que un hallazgo vuelva a aparecer meses después como una sorpresa.
Priorizar exige distinguir impacto de atractivo
Un backlog de auditoría compite con ideas nuevas. Las nuevas suelen ser más emocionantes porque prometen una capacidad visible. Arreglar un sistema de foco o normalizar un contenedor tiene menos brillo. Por eso necesitábamos criterios de prioridad que no dependieran del entusiasmo.
Impacto transversal, bloqueo de otras tareas, riesgo para el usuario, frecuencia y coste de corregir más tarde ayudaban a ordenar. Una mejora de base que desbloquea varias funciones puede ir antes que una feature aislada. Un problema de accesibilidad puede tener prioridad aunque no afecte a la mayoría de sesiones. Una inconsistencia estética pequeña puede esperar si no crea deuda adicional.
Priorizar también significa aceptar que no todo se arregla en la misma fase. Auditar sirve para ver el conjunto y decidir qué no hacer todavía. Esa renuncia explícita protege la atención.
Los números del catálogo dejaron de ser una métrica suficiente
Una fase de crecimiento tiende a convertir el número de elementos en una historia fácil. Pero el tamaño deja de ser útil cuando no distingue estado, calidad o profundidad. Un puzzle presente en el repositorio puede no estar listo para representar públicamente el estándar de la plataforma.
Esta reflexión llevó después a decisiones más estrictas sobre qué significa «disponible» y qué debe aparecer como próximo. El artículo posterior sobre calidad antes que cantidad desarrolla esa evolución. La auditoría fue el paso previo: aprendimos a mirar el catálogo como conjunto de experiencias, no como contador.
Cuando la métrica cambia, cambia el incentivo. Mejorar un juego existente puede valer más que añadir otro. Cerrar una deuda de sistema puede producir más valor que aumentar una cifra pública. Esa transición es difícil precisamente porque el progreso se vuelve menos fotogénico y más profundo.
Auditar también significa comprobar que la arquitectura cuenta la verdad
Una plataforma puede decir que tiene componentes compartidos mientras mantiene copias divergentes. Puede decir que está internacionalizada mientras parte de los textos siguen hardcodeados. Puede decir que soporta temas mientras algunos tableros ignoran variables. La auditoría debe contrastar la narrativa técnica con el repositorio real.
Eso implica buscar excepciones, no solo revisar la ruta feliz. Qué juegos no usan el shell, qué páginas no reciben el mismo header, qué assets siguen rutas antiguas, qué datos se duplican, qué tests cubren realmente variantes. Muchas mejoras posteriores de build y quality gates nacieron de esa actitud.
Automatizar la comprobación de invariantes libera atención humana. Si una regla puede verificarse siempre, no deberíamos depender de recordarla en cada PR. La revisión humana se reserva para lo que una máquina no sabe valorar bien: claridad, ritmo, ergonomía y calidad del puzzle.
El objetivo no era llegar a cero deuda
Una auditoría puede volverse interminable si su meta es perfección. Todo producto activo tiene deuda, compromisos y decisiones temporales. El objetivo real era recuperar control: saber qué problemas existían, cuáles eran deliberados, cuáles tenían prioridad y qué sistema evitaría reproducirlos.
Esa diferencia impide que la consolidación se convierta en una pausa infinita. Cuando la base alcanza un estándar suficiente y las principales causas de divergencia están controladas, el producto puede volver a expandirse con más seguridad. La auditoría no sustituye a construir; mejora la capacidad de construir después.
Parar fue una forma de acelerar el siguiente tramo
Mirado desde fuera, una semana dedicada a consolidar puede parecer más lenta que una semana con varias funciones nuevas. Mirado desde el sistema, puede ser lo contrario. Si un nuevo componente evita duplicación futura, si un cambio de layout resuelve decenas de pantallas o si una taxonomía mejora todo el descubrimiento, el retorno se acumula.
Ese efecto compuesto era lo que buscábamos. La primera fase había demostrado que podíamos construir muchas cosas. La siguiente tenía que demostrar que podíamos hacerlas convivir y evolucionar sin que cada nueva pieza aumentara el caos.
Blupoli Puzzles ha cambiado desde aquella auditoría, pero seguimos utilizando la misma señal para saber cuándo frenar: si añadir otra cosa hace más difícil entender el conjunto, es momento de mirar el sistema. Parar de sumar no es abandonar el ritmo. A veces es la única forma de asegurarse de que la velocidad sigue apuntando en la dirección correcta.