Una empresa nos llama con una petición clara: «necesitamos añadir una nueva sección a la aplicación, ¿cuánto tardaríais?». Sobre el papel, dos semanas de trabajo. Al abrir el código, dos semanas se convierten en dos meses. No porque la nueva sección sea difícil, sino porque el terreno sobre el que hay que apoyarla está mucho peor de lo que nadie imaginaba.
Esta situación se repite cada vez más con la irrupción de la IA. El producto funciona, los usuarios lo usan a diario y, por fuera, todo va bien. Por dentro, en cambio, cada cambio cuesta un poco más que el anterior. Ahí es donde tiene sentido parar y mirar de verdad qué hay debajo.
Qué es una auditoría técnica (y qué no es)
Una auditoría técnica es una revisión a fondo del estado real de un producto de software: cómo está construido, sobre qué se apoya, qué partes son sólidas y cuáles están a punto de dar problemas. No es una opinión sobre si el código es «bonito», es un diagnóstico sobre si aguanta lo que quieres construir encima.
El resultado no es una lista de quejas. Es un mapa: qué está bien, qué hay que vigilar, qué hay que arreglar antes de seguir y, sobre todo, qué riesgo tiene cada decisión que tomes a partir de ahora.
Qué se analiza
Cada producto es distinto, pero hay un conjunto de áreas que casi siempre cuentan la verdad sobre el estado de un proyecto. Se revisan las dependencias (las librerías externas de las que depende el software), la arquitectura (cómo están organizadas las piezas y si esa organización aguanta el crecimiento), la base de datos, la seguridad, la cobertura de tests y la documentación que existe, o que falta.
Ninguna de estas áreas es un detalle menor. Son, precisamente, las que determinan si añadir lo siguiente costará dos semanas o dos meses.
Las sorpresas que aparecen casi siempre
Hay hallazgos que se repiten proyecto tras proyecto, sin importar el sector ni el tamaño de la empresa:
Deuda técnica acumulada. Atajos que en su momento tenían sentido para llegar a tiempo, pero que nadie volvió a tocar. Cada uno, por separado, es inofensivo. Juntos, convierten cualquier cambio en una operación delicada.
Dependencias obsoletas. Librerías que llevan años sin actualizarse, a veces con vulnerabilidades conocidas, a veces simplemente abandonadas por quien las mantenía. El día que necesitas actualizar una, descubres que arrastra otras diez.
Código que nadie sabe qué hace. Cada vez aparece más código generado con IA que se aceptó porque «funcionaba», pero que nadie llegó a entender del todo: bloques enormes, repetitivos y sin una lógica clara detrás. Mientras todo va bien no molesta; el problema llega el día que hay que tocarlo y descubres que no hay nadie (ni persona ni documento) que pueda explicar por qué está hecho así.
Arquitectura que no escala. Decisiones que funcionaban perfectamente con cien usuarios y empiezan a crujir con diez mil. No estaban mal: estaban pensadas para otro momento.
Falta de documentación. El conocimiento del proyecto vive en la cabeza de una persona que quizá ya no está. Sin documentación, cada incorporación al equipo tarda semanas en entender algo que debería estar escrito.
Por qué hacerla antes de seguir construyendo
La tentación, cuando un producto ya funciona, es seguir añadiendo cosas encima. Más funcionalidades, más pantallas, más integraciones. El problema es que cada capa nueva se apoya en la anterior, y si la base no está sana, lo único que haces es construir más alto sobre algo que ya temblaba.
Hacer una auditoría antes de ese siguiente paso te da algo que normalmente no se tiene: información para decidir. A veces el resultado es «todo bien, adelante». Otras veces es «arregla esto primero, te ahorrará meses». En ambos casos, dejas de avanzar a ciegas.
El problema no siempre es añadir; a veces es saber
Es fácil pensar que avanzar significa siempre construir más. Pero hay momentos en los que el paso más rentable no es añadir una sola línea de código, sino entender con precisión en qué estado está lo que ya tienes.
Saber dónde estás no frena el proyecto: es lo que te permite avanzar con la seguridad de que no se va a venir todo abajo en el peor momento.
En Liquid hacemos este tipo de auditorías sobre productos que no hemos construido nosotros. No para reescribirlo todo, sino para darte un diagnóstico honesto y un plan claro de qué hacer a continuación.
