Por qué necesito una checklist para algo "tan simple"
Cuando publiqué el generador de códigos QR gratuito en caprini.dev, di por hecho que, al ser una herramienta pequeña, no necesitaba una revisión exhaustiva antes de publicarla. Me equivoqué. Encontré varios problemas menores solo después de forzar casos de uso que no había probado durante el desarrollo normal: textos muy largos, caracteres especiales, uso desde un móvil con muy poca conexión.
Desde entonces uso una checklist fija antes de publicar cualquier herramienta web pequeña, precisamente porque su tamaño hace que sea tentador saltarse pasos que sí aplicaría a un proyecto más grande.
Privacidad: qué datos toca la herramienta
Lo primero que reviso, antes que cualquier aspecto técnico, es qué datos maneja la herramienta y dónde:
- Si el procesamiento puede hacerse enteramente en el navegador (client-side), sin enviar el contenido introducido a ningún servidor, lo prefiero siempre que sea viable. Esto simplifica enormemente la respuesta a "¿qué hacéis con mis datos?": la respuesta honesta es "nada, no llegan a salir de tu navegador".
- Si necesita un backend, reviso qué se registra en logs por defecto (headers, IPs, contenido de las peticiones) y si eso está documentado en algún lugar accesible.
- Que no queden claves de API ni credenciales expuestas en el código del lado del cliente, algo fácil de olvidar cuando se prueba rápido en desarrollo.
Rendimiento y comportamiento en conexiones lentas
Una herramienta pequeña no está exenta de comprobar cómo se comporta en condiciones reales de red:
- Pruebo la carga inicial simulando una conexión lenta, no solo con la conexión rápida de mi propio entorno de desarrollo.
- Compruebo qué pasa si la persona interactúa con la herramienta antes de que haya terminado de cargar completamente (por ejemplo, si hace clic en generar antes de que la librería necesaria esté lista).
- Reviso el peso de cualquier librería externa que añada solo para una función concreta; a veces una dependencia completa pesa más que reimplementar la parte que realmente necesito.
Casos límite que rompen la herramienta
Este es el bloque donde más fallos suelo encontrar, y donde más tiempo merece la pena invertir:
- Campos de texto vacíos, con solo espacios, o extremadamente largos.
- Caracteres especiales, emojis o texto en alfabetos distintos al latino, especialmente si la herramienta genera algún tipo de codificación (como ocurre con un generador de QR).
- Uso repetido muy rápido de la misma acción (por ejemplo, generar varias veces seguidas sin esperar), para comprobar que no se acumulan procesos ni se rompe el estado de la interfaz.
- Comportamiento al redimensionar la ventana o rotar el dispositivo móvil en mitad de una acción.
Accesibilidad básica que no debería faltar
No hace falta una auditoría de accesibilidad completa para una herramienta pequeña, pero sí un mínimo razonable:
- Que se pueda usar completamente con teclado, sin depender exclusivamente del ratón o del tacto.
- Que los botones y campos tengan etiquetas comprensibles para lectores de pantalla, no solo iconos sin texto alternativo.
- Que el contraste de color sea suficiente para leer el resultado, especialmente en herramientas que generan una imagen o un código sobre fondo claro u oscuro.
Textos legales y de contacto mínimos
Aunque sea una herramienta gratuita y sin cuentas de usuario, reviso que exista:
- Una forma de contacto o de reportar un problema, aunque sea un enlace simple.
- Una nota clara de que la herramienta es gratuita y de uso libre, para evitar confusión sobre si requiere pago en algún paso posterior.
- Coherencia con la política de privacidad general del sitio, si la herramienta vive dentro de un dominio que ya tiene una.
Errores que ya cometí antes de tener esta lista
Antes de sistematizar esta checklist, publiqué una versión temprana de una herramienta con un fallo que solo apareció al introducir un carácter de salto de línea dentro de un campo pensado para texto de una sola línea. La interfaz no se rompía visiblemente, pero el resultado generado era incorrecto sin ningún aviso de error. Ese tipo de fallo silencioso es, para mí, el más peligroso: no avisa de que algo ha ido mal, así que quien lo usa puede terminar compartiendo un resultado defectuoso sin saberlo.
Qué reviso después de publicar, no solo antes
La checklist no termina en el momento de publicar. Durante los primeros días después de sacar una herramienta nueva, reviso con más frecuencia de lo habitual si llega algún error inesperado, aunque no tenga ningún sistema sofisticado de monitorización detrás. En herramientas tan pequeñas como estas, muchas veces la única señal de que algo falla es un mensaje directo de alguien que la ha usado, así que me aseguro de que el canal de contacto sea fácil de encontrar y de que yo mismo revise la herramienta en distintos dispositivos durante esos primeros días, no solo el día de publicarla.
Este seguimiento posterior es, en la práctica, una extensión de la misma checklist: las comprobaciones previas reducen los fallos evidentes, pero solo el uso real, con datos y dispositivos que no había previsto, termina de revelar los que quedan.
Conclusión
El tamaño de una herramienta no reduce la necesidad de revisarla antes de publicarla; solo cambia dónde suelen aparecer los fallos. En proyectos pequeños, los problemas casi nunca están en la lógica principal, que suele ser sencilla y bien entendida, sino en los casos límite que no se prueban porque "total, es una herramienta simple". Esa suposición es, precisamente, la que más veces me ha fallado.