Diagnóstico y auditoría
Antes de tocar nada, miramos lo que ya tienes. A veces el problema no es el que nos cuentas: es el de al lado, el que nadie había mirado todavía.
El equipo
-
Nora
Coordina al equipo entero sin levantar la voz ni una vez.
Sabe qué hace cada uno, cuándo y por qué. Si algo se retrasa, no es cosa suya: ya lo había avisado.
-
Diego
Vive dentro de la lógica que hace funcionar cada aplicación.
Encuentra el error exacto en la línea exacta, normalmente a la tercera taza de café. La cuarta ya es superstición.
-
Lucía
Diseña cada pantalla, cada botón, cada milímetro de cómo se siente usar algo.
Mide los píxeles con una regla de verdad. No es manía: es convicción.
-
Marco
Mantiene todo encendido y accesible, de día y de noche, sin excepciones.
Se agacha junto al servidor y escucha, como si la máquina fuera a confesarle algo. A veces lo hace.
-
Elena
Revisa cada rincón antes de que algo salga a la calle.
Si hay una puerta sin cerrar o una cláusula rara, la encuentra. Ya ha visto cómo acaban las historias que empiezan bien.
-
Iván
Escribe lo que este estudio dice hacia afuera y vigila de reojo lo que dicen los demás.
Tacha más de lo que escribe. La frase buena suele ser la tercera versión de una mala.
-
Bruno
Ilustra y diseña cada imagen que ves en esta página.
Trabaja con la paciencia de quien talla en madera en vez de hacer clic. Si un retrato tarda, es que le está saliendo bien.
-
Alba
Piensa el producto antes de que exista una sola línea de código.
Sabe qué pieza se puede quitar sin que la torre se venga abajo, y cuál no, bajo ningún concepto.
-
Vera
Diseña cómo se organiza y se comunica un equipo que crece.
Con una centralita de las de antes conecta a cada uno con la conversación que le toca. Nadie se ha quedado hablando solo, de momento.
-
Sara
Conoce cada herramienta que usamos y para qué sirve cada una.
Tiene un fichero —mental, y por lo visto también uno de verdad— con una entrada para cada una. Nunca le hemos visto el final al cajón.
Qué hacemos
Diseño y construcción
Desde cero o sobre lo que existe, diseñamos y construimos con una regla simple: si no lo usaríamos nosotros, no lo entregamos.
Publicación y vigilancia
Lo dejamos funcionando y nos quedamos mirando. Literalmente: alguien del equipo está siempre despierto para cuando algo decide portarse mal a las tres de la mañana.
Revisión de lo existente
Si ya tienes algo y no rinde —va lenta, falla, da miedo tocarla—, la abrimos, miramos dentro y te contamos exactamente qué hay que arreglar. Sin rodeos ni frases bonitas.
Léelo entre líneas
Pega un trozo de tu código y te decimos, línea a línea, qué se te ha colado: contraseñas a la vista, comentarios que llevan un año pendientes, un console.log que se te olvidó quitar. Todo pasa aquí, en tu navegador — nosotros no vemos nada, pero tú vas a ver más de lo que esperabas.
Diccionario de lo que te están diciendo
En una reunión, en un presupuesto, en un email: frases que suenan técnicas pero que ocultan decisiones. Aquí descubrirás qué suelen significar de verdad, cuánto te va a costar después y la pregunta exacta que deberías hacerle a quien las dice.
Frases frecuentes:
Quita una pieza
Todo proyecto se sostiene sobre piezas que nadie mira hasta que faltan: un dominio, una contraseña que solo sabe una persona, una copia de seguridad que nunca se ha probado. Toca un bloque de la torre y comprueba cuánto aguanta sin él.
La chapuza, en corte
Por fuera, todo parece perfecto: es lo que enseñan casi todas las webs, incluida cualquiera que no hayamos revisado nosotros. Pulsa el botón y mira dentro — ahí es donde de verdad se sabe si algo funciona o solo lo parece.
- Dos engranajes sin resguardo. Giran a la vista, sin ninguna carcasa que los proteja. Basta que se enganche cualquier cosa ahí para parar el proceso entero.
- Una pieza remendada con cinta adhesiva. Aguanta hoy, y probablemente mañana. Pero es la clase de arreglo que decide romperse justo el día de más visitas.
- Un cable atado con un nudo. Donde debería haber una conexión limpia, hay un nudo tosco. Por ahí, ahora mismo, podrían estar perdiéndose solicitudes de contacto sin que nadie lo note.
- Un tornillo suelto en la base. Se ha caído de donde tenía que ir y nadie lo ha recogido. Si ha salido uno, algo más se ha quedado flojo detrás.
Preguntas que solemos oír
Revisamos webs y aplicaciones. Miramos lo que tienes, te decimos dónde se romperá y qué debes arreglar. A veces construimos desde cero, a veces reparamos lo que ya existe, a veces solo miramos. Siempre sin jerga: la verdad, limpia y verificable.
Depende de lo que sea. Un diagnóstico, entre dos y tres semanas. Un redesign funcional, entre dos y cuatro meses. Una construcción desde cero, entre tres y seis. Las fechas que importan te las contamos en la primera llamada; las que no, las te las diremos igual si hace falta.
Escribes, llamas o nos pasas el link. Miramos lo que describes. Tomamos café (literal, con alguien del equipo). Hablamos de qué tienes entre manos y de qué hace falta de verdad. Luego, o nos encargamos nosotros, o te contamos qué debes hacer tú, o los dos. Nunca vendemos lo que no se necesita.
Trabajamos con ambos. Un startup que necesita no caerse, una web que lleva cinco años sin tocar, una aplicación que se queda lenta después del lanzamiento — todo nos importa igual. El tamaño no determina el oficio; lo hace la precisión. Si tu proyecto merece atención, te la damos.
El informe de nuestra propia web
Esto es lo que le entregamos a un cliente: hallazgos con su severidad, lo que está bien, lo que queda pendiente y lo que hemos decidido asumir y por qué. Lo hemos hecho también con la nuestra.
- Dominio auditado
- trasgolab.mate0s.online
- Fecha de revisión
- 10 de septiembre de 2026
- Firman
- Elena — seguridad y accesibilidad · Diego — medidas
Las cifras
- 0 peticiones a terceros, 0 dependencias externas
- Todo lo que carga la página sale del propio dominio. Nada que filtrar a un tercero, nada que declarar en una política de cookies.
- 28,6 KB pesa todo el código, comprimido
- HTML, CSS y JS juntos. Es lo que de verdad decide cómo funciona la página.
- 98,5 % del peso de la página son imágenes
- El código apenas cuenta: casi todo lo que se descarga al entrar es ilustración, no funcionalidad.
- 5,47 MB suman los diez retratos del equipo
- Una media de 574 KB cada uno, en PNG sin optimizar para ilustración plana. Se cargan solo al llegar a «El equipo», pero de golpe.
- 664 KB de una imagen que ya no usa nadie
hero.pngsigue desplegada y accesible por URL directa. Nada la enlaza desde la página, pero ahí sigue.- 1 120 líneas tiene ya la hoja de estilos
- 178 reglas repartidas en 12 bloques
@media, crecidas feature a feature sin que nadie haya vuelto a ordenarlas. - max-age=0 en todo lo que se descarga
- El navegador revalida cada recurso en cada visita, incluidos los retratos y el CSS, que solo cambian cuando publicamos algo nuevo.
Hallazgos de la auditoría
1. Sin cabeceras de seguridad configuradas por nosotros
No hay vercel.json que fije Content-Security-Policy, X-Content-Type-Options, Referrer-Policy o HSTS. Si Vercel no las añade por defecto, la web no tiene ninguna capa extra de protección si algún día se cuela un script comprometido. No hemos comprobado qué cabeceras sirve realmente Vercel en producción: queda pendiente de verificación real, no se afirma como hecho.
2. Documentación interna publicada sin querer
Sin .vercelignore ni vercel.json que excluya nada del despliegue, identidad/README.md (guía de marca con el racional interno del rebranding), identidad/ejemplo-aplicado.html y los README internos de imagenes/ y de la raíz quedan accesibles por URL directa en producción, aunque no estén enlazados desde la página. Nada lleva datos sensibles, pero es contenido de trabajo interno servido como si fuera público, en el dominio de un estudio que vende justo «revisar lo que no se ve».
3. Nada funciona si el visitante tiene JavaScript desactivado
Las cuatro piezas interactivas (Léelo entre líneas, Diccionario, Quita una pieza, La chapuza) dependen al cien por cien de JS para pintar contenido: sin él, sus contenedores quedan vacíos y el botón «Volver a montarla» no hace nada. No hay ningún <noscript> que lo explique. Lo asumimos como decisión de producto para una landing de estudio, no de e-commerce ni de trámite, aunque un aviso mínimo costaría poco.
4. Contraste ajustado en textos con el color «señal»
El texto en --linea-signal (#3B6F7E) sobre fondo claro —los linea-kicker y los botones de ejemplo del diccionario— da un ratio de contraste de ~4.95:1. Pasa el mínimo AA (4.5:1) para texto normal, pero raspando, sin margen para AAA ni para una pantalla mal calibrada. Se revisará si algún día subimos el nivel de accesibilidad exigido.
5. Bloques retirados de la torre siguen en el árbol de accesibilidad
En «Quita una pieza», al retirar un bloque se le pone disabled y se colapsa visualmente (altura y opacidad a cero), pero no lleva aria-hidden ni hidden. Un lector de pantalla navegando en modo exploración puede toparse con botones «atenuados» que ya no deberían estar ahí. No bloquea el uso, es ruido menor.
6. Sin XSS DOM en ninguna de las piezas interactivas
Los cuatro scripts pintan siempre con textContent / createElement / createTextNode, nunca con innerHTML sobre datos externos. Esto importa especialmente en «Léelo entre líneas», que procesa texto pegado libremente por cualquier visitante: ahí es exactamente donde un descuido habría abierto un XSS, y no lo hay.
7. Sin recursos ni rastreo de terceros
No hay fuentes externas, sin scripts de analítica, sin cookies, sin llamadas de red de ningún tipo. Todo lo que carga la página es local al propio dominio. Nada que filtrar a un tercero, nada que declarar en una política de cookies.
8. Foco visible y semántica ARIA cuidada en lo interactivo
:focus-visible consistente en botones, enlaces, textarea e input; el skip-link al contenido funciona; los widgets usan aria-live, aria-pressed, aria-expanded y aria-controls de forma correcta y no decorativa. Se nota que se ha pensado la navegación por teclado, no solo el ratón.
9. .vercel/project.json no se publica, pero conviene no relajarse
El fichero contiene projectId y orgId (no son credenciales, pero identifican el proyecto en Vercel) y está correctamente excluido en .gitignore. No se publica vía git. El riesgo residual es solo si alguien despliega alguna vez subiendo la carpeta local sin cuidado en lugar de vía git.
Publicamos esto porque es exactamente lo que le enseñaríamos a un cliente sobre su propia web, y porque un informe que solo trae buenas noticias no es un informe: es un folleto.
Hablemos de lo que cede.
Cuéntanos qué tienes entre manos. Te diremos la verdad y, si hace falta, señalamos exactamente dónde está el problema. Seguimos siendo un poco duendes: vemos lo que no se ve a simple vista.
Hablar con Línea