Llega un cliente con una app desarrollada por otro proveedor. A veces porque ese proveedor desapareció, otras porque la relación se rompió, y otras porque sencillamente quiere una segunda opinión antes de invertir más dinero en un producto cuyo estado real desconoce.
En todos estos casos, lo primero que hacemos es una auditoría técnica. No para demostrar que el trabajo anterior fue malo, sino para saber exactamente con qué estamos trabajando: qué funciona, qué es frágil, qué está generando deuda técnica y qué podría convertirse en un problema serio si no se aborda.
Este artículo explica cómo estructuramos ese proceso y qué encontramos habitualmente.
Lo primero que revisamos es cómo está organizado el código a nivel global. Esto incluye la separación de capas (frontend, backend, base de datos), cómo se gestionan los entornos de desarrollo y producción, y si existe alguna documentación técnica que explique las decisiones de diseño.
Un proyecto bien estructurado es un proyecto mantenible. Cuando la arquitectura es caótica, cada modificación futura cuesta el doble y el riesgo de romper algo sin querer se multiplica.
Señales de alerta frecuentes en esta fase:
Todo el código en un único archivo o repositorio sin estructura.
Lógica de negocio mezclada con código de presentación.
Variables de configuración hardcodeadas en el código fuente.
Ausencia total de entorno de pruebas separado del de producción.
Revisamos el código fuente para evaluar su calidad real: consistencia de estilo, uso de patrones de diseño, nivel de complejidad y facilidad para entender qué hace cada parte.
Un código ilegible no es solo un problema estético. Es un multiplicador de costes: cualquier desarrollador nuevo necesita el doble de tiempo para entenderlo, y el riesgo de introducir errores al modificarlo es mucho mayor.
Aquí también revisamos si existe cobertura de tests. En la mayoría de proyectos heredados, no existe. Eso no siempre es un problema crítico, pero sí condiciona cómo se puede evolucionar el producto con seguridad.
La base de datos es, con frecuencia, donde están los problemas más costosos de resolver. Revisamos el esquema de datos, la consistencia de los modelos, el uso de índices y la presencia de consultas que podrían degradar el rendimiento al escalar.
Problemas habituales que encontramos:
Tablas sin claves primarias definidas correctamente.
Ausencia de índices en columnas que se usan como filtros frecuentes.
Relaciones entre tablas sin integridad referencial.
Datos críticos almacenados en texto plano sin cifrado.
Consultas que recuperan toda una tabla cuando solo necesitan unos pocos registros.
Una base de datos mal diseñada no suele dar problemas con pocos usuarios. Pero cuando el volumen crece, los problemas aparecen de forma abrupta y son difíciles de resolver sin intervenciones profundas.
La seguridad es el apartado que más sorpresas desagradables suele traer. No porque los proyectos sean intencionalmente inseguros, sino porque en proyectos con presión de entrega los controles de seguridad son los primeros en omitirse.
Revisamos los puntos más críticos:
Autenticación y autorización: cómo se gestionan los accesos y si los permisos están correctamente implementados en el backend (no solo en el frontend).
Exposición de datos sensibles: si hay información personal, financiera o confidencial que se envía o almacena sin el nivel de protección adecuado.
Validación de entradas: si la aplicación valida correctamente los datos que recibe, o si es vulnerable a inyecciones SQL o XSS.
Dependencias con vulnerabilidades conocidas: librerías desactualizadas que tienen CVEs públicos documentados.
Secretos en el repositorio: claves de API, credenciales o tokens comprometidos en el historial de commits.
Este es el apartado donde más frecuentemente encontramos problemas que requieren acción inmediata antes de cualquier otra consideración.
Auditamos cómo está desplegada la aplicación: qué proveedor de hosting se usa, si hay redundancia, cómo se gestionan los backups, y si el proceso de despliegue es manual o automatizado.
Una app sin proceso de despliegue automatizado (CI/CD) depende de una persona concreta para actualizarse. Si esa persona no está disponible, el proceso se detiene. Y una app sin backups verificados no tiene backups reales, tiene la ilusión de tenerlos.
También evaluamos los costes de infraestructura. En proyectos heredados es frecuente encontrar recursos sobredimensionados que se pagan sin necesidad, o configuraciones que funcionarían igual con la mitad del gasto.
Analizamos los tiempos de carga, la respuesta de la API bajo carga normal y cómo se comporta la aplicación cuando varios usuarios la usan simultáneamente. Esto incluye una revisión del frontend: tamaño de los assets, uso de caché, optimización de imágenes y comportamiento en dispositivos móviles.
Una app lenta no es solo una mala experiencia de usuario. Es una app que pierde conversiones, genera fricción innecesaria y comunica una imagen de producto poco cuidado.
Toda aplicación tiene deuda técnica. El objetivo de la auditoría no es eliminarla, sino cuantificarla y priorizarla. Al finalizar el proceso, entregamos una clasificación de los hallazgos en tres niveles:
Críticos: problemas que deben resolverse antes de continuar. Generalmente relacionados con seguridad o estabilidad.
Importantes: problemas que no bloquean el funcionamiento actual, pero que aumentan el coste y el riesgo de cada cambio futuro.
Mejoras: optimizaciones que mejorarían el rendimiento, la mantenibilidad o la experiencia de usuario, pero que pueden planificarse sin urgencia.
Con esta clasificación, el cliente puede tomar decisiones informadas sobre si refactorizar, migrar o directamente reconstruir partes del sistema.
La auditoría no es un fin en sí mismo. Es el punto de partida para tomar decisiones con criterio: si vale la pena seguir construyendo sobre la base existente, qué hay que sanear antes de escalar, o si tiene más sentido replantear la arquitectura desde cero.
En algunos casos, la conclusión es que el producto está en mejor estado del esperado y que basta con abordar unos pocos puntos críticos. En otros, la auditoría confirma que seguir invirtiendo en la dirección actual es tirar dinero.
En ambos casos, es información que vale la pena tener antes de comprometer más presupuesto.
La satisfacción de nuestros clientes es nuestra mejor carta de presentación.
"Tengo un negocio de Paquetería, en el que vienen muchas personas diariamente, tanto para recoger como para dejar paquetes. Llevábamos años gestionando muchos de nuestros procesos de paquetería de forma manual, y gracias a Blimbur Technologies hemos dado un salto enorme. Nos desarrollaron una app móvil y una web totalmente adaptadas a nuestro flujo de trabajo, con las que ahora tenemos todo automatizado, trazable y mucho más rápido. Ahora, el cliente sabe si tenemos el paquete y al estar todo mucho más organizado, es mucho más rápido y ágil, lo que hace que los clientes vengan y se vayan con otra cara y sin esperas. El trato ha sido impecable y el resultado, todavía mejor. Un equipo serio, técnico y que se implica de verdad."
