auditoría técnica de tu aplicación web: qué incluye, cuánto cuesta y cuándo la necesitas.

tu aplicación web ya no es un proyecto: es el negocio. y el momento más caro para descubrir que está construida sobre cimientos frágiles es justo cuando empieza a crecer — más clientes, más datos, más presión — y de repente cada cambio chico tarda semanas y nadie sabe explicarte por qué.

una auditoría técnica responde una pregunta de negocio, no de código: ¿puedo seguir invirtiendo sobre lo que tengo, o estoy poniendo plata sobre una base que va a fallar? acá va lo que incluye una auditoría seria, cuánto cuesta, qué necesitas tener listo y cómo reconocer las auditorías de humo que abundan en el rubro.

// cuándo la necesitas: señales que puedes ver sin leer código

no necesitas ser técnico para detectar deuda técnica. se nota en la operación:

• -cada feature nueva tarda más que la anterior, aunque parezca más simple.
• -un cambio en una parte del sistema rompe otra que no tiene relación aparente.
• -la cuenta de hosting o cloud sube mes a mes más rápido que tus ventas.
• -una sola persona sabe cómo funciona todo — y si se va, nadie puede tomar el código.
• -incorporar a un developer nuevo toma semanas porque no hay documentación ni convenciones.
• -el equipo evita hacer deploy los viernes 'por si acaso'.

// qué incluye una auditoría técnica seria

una auditoría real lee tu código, tu infraestructura y tu operación. esto es lo mínimo que debe cubrir — y lo que deberías exigir por escrito en la propuesta antes de pagar:

1. arquitectura y datos

cómo está estructurado el sistema y cómo conversa con la base de datos: queries n+1 que multiplican el trabajo del servidor, índices faltantes en las consultas que más se ejecutan, migraciones sin versionar. aquí viven los hallazgos más rentables de todo el ejercicio: a veces un índice que tu equipo aplica en una tarde resuelve lo que parecía exigir meses de reescritura.

2. seguridad superficial

esto no es un pentest — y quien te venda una auditoría general como si lo fuera te está mintiendo. lo que sí cubre es la superficie obvia que explica la mayoría de los incidentes evitables: credenciales y llaves guardadas dentro del repositorio, dependencias con vulnerabilidades conocidas, formularios de login sin límite de intentos, permisos de origen (cors) abiertos a cualquiera. si tu aplicación maneja datos de clientes, esta capa no es opcional.

3. performance real, medida en producción

lo que mide google y lo que siente tu cliente: core web vitals sobre tráfico real, peso de javascript por página, imágenes sin optimizar. el umbral oficial de google para lcp — cuánto tarda en aparecer el contenido principal — es 2.5 segundos; sobre eso pierdes posiciones de búsqueda y conversiones al mismo tiempo. una auditoría seria mide tu url en producción, no una demo en el computador del developer.

4. deuda técnica y dependencias

qué tan caro es mantener y extender el código hoy: versiones de framework cerca del fin de soporte, librerías abandonadas, ausencia de tests justo en los flujos que generan ingresos, tipos laxos donde un error de datos cuesta plata. la deuda técnica opera como un impuesto sobre cada hora de desarrollo futuro — la auditoría no lo elimina, pero te muestra dónde está concentrado y cuál conviene pagar primero.

5. bus factor: ¿de quién depende tu negocio?

la capa que casi nadie audita y la que más duele en pymes chilenas: ¿el repositorio es de tu empresa o está en la cuenta personal de alguien? ¿el dominio y el hosting están a tu nombre o al de la agencia que ya no contesta? ¿hay una persona que, si renuncia mañana, deja tu producto huérfano? es más común de lo que parece encontrar operaciones completas colgando de un freelancer que dejó de responder correos. una auditoría seria entrega el inventario de accesos y un plan para que el conocimiento crítico no viva en una sola cabeza.

lo que puedes correr tú hoy, gratis

# performance según google, sobre tu url real
npx lighthouse https://tu-app.cl --only-categories=performance

# dependencias con vulnerabilidades conocidas
npm audit --audit-level=high

# dependencias desactualizadas
npm outdated

estas herramientas son el punto de partida, no la auditoría. te dicen qué síntomas existen; no te dicen qué causa conviene arreglar primero ni cómo hacerlo sin congelar el desarrollo. si un proveedor te entrega solo la salida de estas herramientas con formato bonito, no compraste una auditoría: compraste un pdf.

// el entregable: un plan, no un informe

el resultado no debería ser un documento de 80 páginas que nadie va a leer. debería ser un plan de remediación priorizado: cada hallazgo clasificado por impacto en el negocio y esfuerzo de corrección, una secuencia que tu equipo puede ejecutar sin detener el desarrollo activo, y claridad sobre qué resolver con tu gente y qué conviene delegar. si el entregable no te permite tomar decisiones de inversión, recibiste un diagnóstico sin tratamiento.

"una auditoría no se paga con el informe: se paga con la primera mala decisión que te evita."

// cuánto cuesta y cuánto demora

hablemos de plata, porque casi nadie lo pone por escrito. en mi lista de precios los proyectos parten en $1.000.000 clp — y la auditoría técnica es exactamente eso: la puerta de entrada. es el proyecto más chico que puedes contratar conmigo y el que más información entrega por peso invertido. compáralo contra las alternativas reales: seguir pagando meses de desarrollo sobre una base que quizás hay que corregir, o aprobar una reescritura completa que quizás no era necesaria.

en tiempo, una auditoría se mide en días o semanas según el tamaño del código — no en meses. de tu lado necesitas tener listo: acceso de lectura al repositorio, acceso a un ambiente de prueba si existe, y visibilidad de tus facturas de hosting o cloud. nada de esto le entrega control de tu sistema al auditor: leer no es tocar.

// red flags: cómo reconocer una auditoría de humo

• -no piden acceso al repositorio: sin leer el código no hay auditoría, hay opinión.
• -el informe es la salida de una herramienta automática con un logo encima.
• -todo aparece marcado como crítico: un informe sin prioridades es tan inútil como no tener informe.
• -la conclusión siempre es 'hay que reescribir todo desde cero'… y casualmente el mismo proveedor vende la reescritura.
• -prometen ahorros con cifras exactas antes de haber medido nada en tu sistema.
• -nunca hablan con la persona que mantiene el código hoy.

// siguiente paso

si reconociste tu operación en las señales de arriba, hay dos formas de partir esta semana: el diagnóstico interactivo de deuda técnica en /diagnostico, o una conversación directa en /contacto. si quieres contexto antes, en /servicios está cómo la auditoría se conecta con el resto del trabajo, en /proyectos está el trabajo real en producción, y la nota /notas/deuda-tecnica-silenciosa-senales explica cómo gestionar deuda técnica sin contratar un cto a tiempo completo.