La mayoría de empresas NO auditan su software. Las que lo hacen se arrepienten de no haberlo auditado antes.
Hace unos meses me escribió el responsable de una empresa del sector salud con cientos de clientes y planes de multiplicarlos.
Llevaban 5 años desarrollando un nuevo sistema para reemplazar uno anterior que se les había quedado corto.
Habían invertido mucho tiempo y dinero.
Por el camino cambiaron de equipo más de una vez porque o no cumplían con los plazos o no entregaban lo que prometían.
Aun así, consiguieron poner el nuevo sistema en producción para algunos centros.
No era perfecto, pero funcionaba.
O al menos eso parecía.
El siguiente paso era escalarlo a toda la compañía. Pasarían de tener cientos de usuarios a miles.
Pero antes de escalar, necesitaban estar seguros de que este nuevo software realmente estaba preparado.
Y no les faltaban razones para dudar.
Estaban pagando un dineral en infraestructura porque el sistema necesitaba cada vez más recursos para hacer lo mismo.
Había errores que aparecían y desaparecían sin explicación.
Y cada vez que alguien tocaba el código, algo se rompía en otro sitio.
Sabían que tenían un problema. Lo que no sabían era lo grande que era.
Bien.
Cuando me dieron acceso al código, lo que encontré fue peor de lo que esperaban.
Agujeros de seguridad que, si alguien los encontraba antes que yo, habrían tenido un problema muy serio.
Código sin separación de responsabilidades. Las reglas del dominio, el acceso a datos, el envío de emails, la generación de PDFs, todo acoplado en los mismos módulos.
Una arquitectura diseñada para un proyecto pequeño que había crecido sin control, con toda la lógica de negocio desperdigada por toda la aplicación.
Queries que traían tablas enteras a memoria para luego filtrar. Patrones de acceso a datos que multiplicaban las consultas por cada registro.
Sin paginación, sin cache, sin ningún tipo de optimización.
El sistema trabajaba 100 veces más de lo necesario y la infraestructura pagaba la factura.
Infraestructura que por supuesto estaba cogida con pinzas: sin backups, sin observabilidad, sin trazabilidad, sin forma de saber si algo fallaba hasta que alguien llamaba.
Y para rematar, ni un solo test decente en todo el proyecto.
La deuda técnica acumulada era tan profunda que seguir construyendo encima no tenía sentido.
El problema no es que tu software tenga deuda técnica. El problema es que no la tengas identificada y se te acabe yendo de las manos.
Todos los proyectos de software acumulan deuda técnica.
Es inevitable.
Lo que no es inevitable es seguir tomando decisiones sin saber dónde está el problema real.
He visto de todo.
Equipos que invierten semanas en migrar a otro framework cuando el verdadero cuello de botella está en que no tienen buenos tests ni una arquitectura preparada para crecer.
CTOs que contratan más developers para ir más rápido, sin darse cuenta de que el código estaba tan acoplado que más gente solo significaba más conflictos.
Y últimamente, empresas que confían en la IA para agilizar el desarrollo sin entender que la IA amplifica lo que ya hay. Si el contexto es malo, la deuda técnica se acumula más rápido.
Pero no siempre todo es tan grave. A veces la solución es sorprendentemente sencilla.
Unos índices bien puestos. Un patrón de acceso a datos corregido. Un acoplamiento eliminado. O incluso cubrir con tests ese módulo que nadie se atreve a tocar.
Cambios que se aplican en días y que tienen un impacto tremendo en el proyecto.
Pero para saber qué hay que hacer, primero necesitas entender lo que hay.
Y para eso hace falta alguien de fuera.
Alguien que mire tu código sin los sesgos de quien lo ha escrito, sin las prisas de quien tiene que entregar features y con la experiencia de haber visto docenas de proyectos en producción.
Y precisamente esa es la idea detrás de las auditorías de Software Sostenible.
Las 6 dimensiones de la auditoría
No es una revisión superficial. No es un informe generado por una herramienta con un montón de métricas vacías. Es un análisis a fondo donde me meto de lleno en tu proyecto.
La auditoría cubre 6 dimensiones: tests, código, arquitectura, seguridad, rendimiento e infraestructura.
- Calidad de los tests
Empiezo por los tests porque ningún estándar ISO lo hace. Los tests automatizados son la red de seguridad que permite modificar código con confianza.
Sin buenas pruebas no se puede refactorizar y sin refactorizar no se puede mejorar ninguna de las demás dimensiones.
Cualquier cambio puede romper funcionalidad existente sin que nadie lo detecte hasta que llegue a producción. Con tests frágiles (exceso de mocks, acoplados a implementación) la situación no mejora, dan falsa seguridad.
- Calidad del código
La calidad del código determina cuánto cuesta hacer un cambio.
Módulos, clases o funciones con múltiples responsabilidades, baja cohesión y alto acoplamiento, nombres que no dicen nada, lógica duplicada...
Lo que en la industria llamamos code smells. Señales de degradación. El código funciona, pero cada cambio cuesta más de lo que debería incluso con la IA.
- Arquitectura y diseño
Cómo están organizados los módulos, cómo fluyen las dependencias, dónde vive la lógica de negocio. Si hay separación, o no, entre el dominio y la infraestructura.
Existen enfoques como Arquitectura Hexagonal o Clean Architecture que resuelven esto. Su principio es simple: la lógica de negocio es el centro del sistema y no depende de nada externo. Ni de la base de datos, ni del framework, ni de servicios de terceros. Si mañana cambias cualquiera de esos, el dominio no se toca.
Evalúo si tu proyecto sigue estos principios o si la lógica de negocio está desperdigada entre controladores, servicios y repositorios sin ningún criterio.
Una buena arquitectura permite evolucionar durante años. Una mala te frena cada día un poco más.
- Seguridad y protección de datos
La seguridad merece capítulo propio.
Si tu software maneja datos de clientes, datos personales o datos de salud o financieros, esto no es opcional. Un descuido aquí puede costarte una multa, una demanda o la confianza de tus clientes.
Y lo he visto más veces de las que me gustaría.
Reviso las dependencias vulnerables, cómo gestionas los secretos, la autenticación, la autorización, el cifrado y la validación de entrada.
Aparte de eso, reviso la configuración de seguridad (HTTPS, CORS, headers), si hay información expuesta que no debería estarlo (logs con datos sensibles, stack traces, documentación de API abierta en producción), y si el código es vulnerable a inyección o deserialización insegura. Son los agujeros que no se ven en una revisión superficial pero que un atacante encuentra rápido.
Todo esto sin olvidar el cumplimiento regulatorio si tu proyecto está sujeto a normativa (GDPR, LOPDGDD, AI Act, LFPDPPP...).
- Rendimiento y escalabilidad
El rendimiento determina cuánto te cuesta escalar.
Y muchas veces lo que parece un problema de servidor es un problema de código disfrazado.
Busco patrones de acceso a datos ineficientes, queries sin optimizar, falta de paginación, falta de cache. También analizo la concurrencia, cómo se comunican los servicios y el frontend.
Si estás pagando más infraestructura de la que deberías, normalmente la respuesta está aquí.
- Infraestructura y procesos
La base sobre la que corre todo tu software.
Miro los entornos, la capacidad de escalar tanto horizontal como vertical, las pipelines de CI/CD, despliegues, la observabilidad, la trazabilidad, los backups y la capacidad de recuperación ante desastres. Si la base falla, da igual lo bien que esté el código.
Y no es raro encontrarme backups que nunca se han probado (o peor, almacenados en la misma región que los datos), monitorización que vive en un dashboard que nadie abre y alertas que llegan tarde.
El día que algo falla, el primero en enterarse es tu cliente.
El proceso paso a paso
- 1. Reservas la auditoría.
Un poco más abajo te cuento cómo.
- 2. Te envío un cuestionario para entender en qué punto estás y preparar bien la primera llamada.
Con esto ya sé qué necesito de ti y qué voy a mirar primero.
- 3. Discovery call.
Me cuentas tu proyecto, tu equipo, tus prioridades y qué te preocupa. Aprovechamos para dejar los accesos listos (repositorios, entornos, lo que haga falta).
- 4. Análisis de las 6 dimensiones.
Trabajo durante 2 o 3 semanas analizando tu proyecto a fondo y preparando el informe.
- 5. Entrega del informe y call final.
Repasamos el informe juntos. Te explico cada hallazgo, te respondo a las dudas y priorizamos los siguientes pasos según impacto y esfuerzo.
- 6. Soporte post-entrega.
Durante las semanas siguientes puedes escribirme por email con cualquier duda que te surja al releer el informe o al empezar a aplicar las recomendaciones.
Qué te llevas en el informe
No te llevas un documento genérico con tu logo. Te llevas un análisis completo de tu proyecto, con tu contexto y tus prioridades.
Dentro encontrarás:
- Resumen ejecutivo.
Lo que necesita saber cualquier persona de tu equipo que no vaya a leer el resto del informe. Riesgos en orden de gravedad, estado general del proyecto y una recomendación directa. Sin tecnicismos.
- Contexto del proyecto.
Qué hace tu sistema, con qué stack, qué equipo lo mantiene y qué te preocupa a ti. Porque un mismo hallazgo puede ser crítico o irrelevante dependiendo de lo que haga el sistema y de a cuántos usuarios afecte.
- Puntos críticos.
Los riesgos que no pueden esperar. Problemas de seguridad, configuraciones peligrosas, bugs que pueden afectar a tus clientes. Cada uno con explicación de por qué es urgente y cómo mitigarlo.
- Hallazgos por cada una de las 6 dimensiones.
Lo que he encontrado en tests, código, arquitectura, seguridad, rendimiento e infraestructura. Cada hallazgo con su evidencia concreta (archivo, línea, ejemplo de código cuando aplica), su severidad y qué hacer para arreglarlo.
- Deuda técnica clasificada por severidad.
No toda la deuda técnica es igual. Hay deuda con la que puedes convivir años sin problema, y hay otra que está lastrando tu proyecto cada día sin que lo sepas. Te digo cuál es cuál, con ejemplos concretos (falta de cohesión, acoplamiento excesivo, code smells, etc.)
Porque el 80% del coste normalmente está en el 20% de la deuda. Y es ese 20% el que hay que identificar.
- Análisis de rendimiento.
Los puntos donde tu sistema está trabajando de más. Queries que traen más datos de los necesarios, patrones de acceso ineficientes, respuestas sin paginar, ausencia de cache. Todo documentado con ejemplos concretos y estimación del impacto.
- Vulnerabilidades de seguridad.
Todo lo que podría explotarse y con qué consecuencias. Dependencias con CVEs conocidos, secretos expuestos, endpoints desprotegidos, cifrado débil, configuración insegura.
Y una revisión específica de qué normativa de protección de datos te aplica (GDPR, LOPDGDD, AI Act, LFPDPPP...) y si tu sistema cumple. Con severidad y plan de mitigación para cada hallazgo.
- Quick wins.
Esas cosas pequeñas con impacto grande. Un índice bien puesto, una query optimizada, una dependencia actualizada.
Cambios que tu equipo puede aplicar en días y que te van a dar un retorno inmediato.
- Plan de acción priorizado por impacto y esfuerzo.
Un roadmap en tres fases: inmediato, corto plazo y medio plazo.
Cada acción con su esfuerzo estimado, su impacto esperado y por qué está en esa fase. Para que tomes decisiones con datos, no por intuición.
- Recomendación técnica.
Si el sistema necesita crecer, te digo cómo prepararlo. Si necesita simplificarse, también.
Y si la mejor decisión es refactorizarlo o reescribir ciertas partes, te lo digo con los números encima de la mesa.
Para quién es esto
Para CTOs, tech leads y fundadores técnicos que tienen un software en producción y necesitan respuestas.
- Llevas años desarrollando un proyecto y no sabes cuánta deuda técnica has acumulado.
- Vas a escalar y quieres saber si el sistema aguanta antes de descubrirlo en producción.
- Estás pensando en contratar más developers y no quieres que hereden un desastre (ni que se vayan a los dos meses por la frustración).
- Has cambiado de equipo y necesitas un diagnóstico honesto de lo que te han dejado.
- Tu equipo te dice que todo va bien pero tú tienes dudas. Y necesitas a alguien externo que te diga la verdad.
- Quieres integrar IA en tu producto o en tu proceso de desarrollo y antes quieres saber si tu base técnica está lista para sacarle partido.
Si tu software es crítico para tu negocio y no tienes claro el estado real del código, la Auditoría de Software Sostenible te da esa claridad.
Para quién NO es esto
- Si tu proyecto está en fase de prototipo o MVP.
Todavía no necesitas una auditoría. Primero valida la idea y vuelve cuando tengas algo en producción.
- Si buscas a alguien que te reescriba el sistema desde cero.
La auditoría es un diagnóstico, no una ejecución. Si después del informe decides que necesitas refactorizar o reescribir, podemos hablarlo. Pero primero hay que saber en qué punto estás.
- Si lo que necesitas es un developer que meta mano al código.
La auditoría es un servicio de consultoría. Yo analizo, diagnostico y te doy un plan. La ejecución puede hacerla tu equipo, el mío, o ambos.
- Si no estás dispuesto a escuchar que tu software tiene problemas.
Mi trabajo es contarte lo que hay, no lo que quieres oír. Si lo que buscas es que alguien te dé la razón, esto no es para ti.
Muy bien, ¿y cuánto cuesta una auditoría así?
Como dice Warren Buffet: "precio es lo que pagas, valor es lo que recibes".
O dicho de otra forma, solo el necio confunde valor con precio.
La pregunta es, ¿cuánto vale para tu empresa algo así?
No solo por las tres semanas de análisis a fondo, las dos llamadas y el informe detallado. Sino por todo lo que una auditoría como esta te puede ahorrar.
El coste de la ignorancia no se ve en la contabilidad. Está en developers frustrados que acaban marchándose. En bugs que llevan meses sin resolver. En decisiones tomadas por intuición que luego no salen. En una factura de cloud que crece sin explicación. En la sensación constante de que algo no va bien y no sabes qué.
Yo tengo claro lo que pagaría si fuera mi empresa.
¿10.000€?
¿15.000€?
(¿15.000€, Miguel? Exagerado…)
Te aseguro que hay consultoras que cobran mucho más por mucho menos. Y normalmente te mandan un junior con un checklist genérico.
Pero claro, yo soy yo, y mis circunstancias.
Aun así, había que poner una cifra. Y esta es la de ahora (probablemente en el futuro suba):
4000€
Eso es todo.
Si lo prefieres, puedes dividir el pago en dos: 50% al confirmar y 50% al entregar el informe.
Auditoría de Software Sostenible
El código importa, pero el contexto más
4000€(Opción de pago en 2 plazos)RESERVAR AHORA
Secured by Stripe with AES-256 EncryptionPreguntas que quizás te estás haciendo
¿La auditoría me da algún tipo de certificación?
No. Y hay una diferencia importante. Las certificaciones evalúan procesos y compliance, no la calidad de tu software. Puedes estar certificado en ISO XXX sin un solo test y sin ningún principio de arquitectura limpia.
Yo analizo tu código, tu arquitectura, tus tests, tu infra. Lo que de verdad determina si tu software es sostenible o no.
Si después quieres ir a por el sello de 20000€, al menos sabrás en qué punto estás.
¿Qué tecnologías cubres?
La auditoría es agnóstica al lenguaje y cubre backend, frontend e infraestructura. Los problemas de diseño, arquitectura, testing y seguridad son similares en TypeScript que en .NET o en Scala con la JVM.
La infraestructura también es agnóstica. He trabajado con AWS, Azure, DigitalOcean, Google Cloud y servidores dedicados.
Si tu stack es muy específico, escríbeme y lo hablamos.
¿Cuánto tardas en entregar el informe?
Entre 2 y 3 semanas desde la primera llamada. Puede variar ligeramente dependiendo del tamaño del proyecto.
¿Puedo contratar la auditoría para varios proyectos?
El precio base cubre un proyecto de hasta 3 repositorios. Si tienes varios proyectos o más repositorios, hablamos y ajustamos el alcance y el precio.
¿Qué pasa si después de la auditoría necesito ayuda para implementar los cambios?
Podemos hablarlo. Ofrezco servicios de consultoría y acompañamiento. Pero primero lo primero: saber qué tienes. Las decisiones se toman después del diagnóstico, no antes.
¿Hay garantía de devolución?
No. Si no tienes claro que te compense, mejor no la contrates.
¿Y si el código está bien y no hay nada que arreglar?
Pues mejor. Te llevas la tranquilidad de saber que tu proyecto está en buen estado. Pero en más de 20 años, nunca me ha pasado.
¿Se puede pagar a plazos?
Sí. Puedes dividir el pago en dos: 50% al confirmar y 50% al entregar el informe.
¿Aceptas PayPal?
No. El pago se gestiona a través de Stripe, una pasarela de pago segura que utilizan la mayoría de negocios serios en internet.
Además, nadie tiene acceso a los datos de tu tarjeta, ni yo ni la plataforma.
¿Puedo pagar por transferencia o criptomonedas?
Sí. Escríbeme y te explico cómo.
¿Haces factura?
Sí. Solo tienes que rellenar tus datos de facturación al comprar y la recibirás en 48h.
¿Haces descuentos?
Nunca hago descuentos. Ni por Black Friday, ni por Navidades, ni por el día del programador.
Hoy siempre será el día en el que encuentres el mejor precio al que puedes contratar esta auditoría. Mañana el precio será el mismo que hoy o mayor, pero nunca inferior.
¿Tienes alguna otra pregunta?
Cualquier duda que tengas sobre estas u otras cuestiones me escribes un email y te responderé lo antes posible.
Auditoría de Software Sostenible
El código importa, pero el contexto más
4000€(Opción de pago en 2 plazos)RESERVAR AHORASecured by Stripe with AES-256 Encryption