Heredaste un producto: la auditoría de código antes de seguir

Heredar un producto es quedarte a cargo de un software que construyó otra persona: el desarrollador se fue, la agencia terminó el contrato, o el código pasó por tantas manos que ya nadie sabe con certeza qué hace. Tienes un producto que funciona —o que funciona a medias— y ninguna forma confiable de saber qué tan sano está por dentro. Una auditoría de código es la respuesta a esa pregunta antes de gastar el primer dólar en cambios: alguien lee lo que hay, lo contrasta con lo que tu negocio necesita y te entrega un veredicto escrito sobre qué conservar, qué reparar y qué reescribir. Escribo esto porque es la mitad de mi trabajo y porque la decisión que se toma sin auditoría casi siempre es la cara.

Resumen para perezosos

• Antes de pedir funcionalidades nuevas sobre un producto heredado, necesitas saber qué tienes. Eso se responde con una auditoría del código y la arquitectura que termina en un documento, no en una conversación.
• La auditoría no revisa solo el código: revisa quién es dueño de las cuentas, qué tan caro es sostener el producto y qué riesgos ya están activos. Varios de los hallazgos más urgentes nunca son técnicos.
• "Reescribir todo desde cero" es la recomendación más frecuente de quien llega nuevo y la más cara para ti. Casi siempre hay un núcleo que se conserva y tres cosas concretas que se reparan.

En este artículo:

• Fundamentos — Qué significa heredar un producto · Por qué lo primero no es programar
• La auditoría — Qué se revisa · Qué dice el veredicto escrito · Cuánto dura y qué pasa después
• Decidir — Conservar, reparar o reescribir · Las señales de alarma · Qué hay que reunir

Qué significa heredar un producto

Los casos llegan casi siempre en una de estas formas:

• El desarrollador se fue. Trabajaba solo, tenía todo en la cabeza y dejó un repositorio sin documentación. A veces sigue respondiendo mensajes por un tiempo; a veces no.
• La agencia terminó y desapareció. Entregó una versión que funcionaba el día de la entrega. Seis meses después nadie contesta y el contrato no dice qué pasa con las cuentas.
• El código se desordenó con los años. Nadie se fue: el producto acumuló cambios pequeños y urgentes hasta que cada modificación nueva rompe algo viejo y ya nadie se atreve a tocar ciertas partes.
• Compraste el producto. Adquiriste una empresa o una aplicación y el software vino incluido, sin que nadie de tu lado lo haya revisado nunca.

En los cuatro el punto de partida es el mismo: existe un producto que tus usuarios usan y tu equipo no puede responder preguntas básicas sobre él. Cuánto cuesta mantenerlo al mes. Qué pasa si se cae un martes a las nueve de la noche. Si los datos de tus usuarios están donde deberían. Cuánto trabajo real hay detrás de la funcionalidad que quieres agregar el mes que viene.

No saber esas respuestas no es una falla de gestión. Es el estado normal de un producto que cambió de manos sin traspaso. Lo que sí es una falla es seguir construyendo encima sin resolverlo.

Por qué lo primero no es programar

La reacción natural cuando heredas un producto es pedir lo que te hace falta: arreglar el error que reportan los usuarios, agregar la pantalla que te pidió un cliente, publicar la versión nueva. Es razonable y casi siempre sale mal, por tres motivos.

No sabes lo que estás tocando. En un código que no conoces, un cambio de veinte líneas puede ser de veinte líneas o de tres semanas. Nadie puede cotizarte de verdad sin haber leído lo que hay, y quien te dé un precio sin leerlo lo está adivinando.

No sabes qué está en riesgo ahora mismo. Las cosas que más urgen en un producto heredado rara vez son las que se ven desde afuera. Una llave de acceso publicada en el repositorio, una base de datos sin copias de respaldo o un servicio que dejó de recibir actualizaciones de seguridad no aparecen en la lista de pendientes de nadie, y cualquiera de las tres puede costarte el producto entero.

No sabes si conviene seguir con eso. A veces la respuesta honesta es que el código no vale lo que cuesta mantenerlo, y esa es una decisión de negocio que necesitas tomar con información, no después de haber invertido seis meses en mejorarlo.

Una auditoría cuesta una fracción de lo que cuesta el primer mes de desarrollo a ciegas. Ese es todo el argumento.

Qué se revisa en una auditoría de código

Son ocho áreas, y el orden importa. Las primeras no son técnicas, y eso es deliberado: de nada sirve un diagnóstico impecable del código si resulta que la cuenta de la tienda de aplicaciones está a nombre de alguien que ya no contesta.

Área	La pregunta que responde
Propiedad y accesos	¿Quién es dueño hoy del código, los dominios, las cuentas y las llaves?
Infraestructura y costos	¿Dónde vive el producto y cuánto cuesta al mes sostenerlo?
Arquitectura	¿Cómo está dividido el sistema y qué partes dependen de qué?
Código	¿Qué tan legible y modificable es, y dónde se concentra el desorden?
Dependencias y versiones	¿Qué tan viejo es lo que usa y qué ya no recibe actualizaciones?
Datos y seguridad	¿Dónde están los datos de tus usuarios, quién los ve y hay copias de respaldo?
Publicación y entornos	¿Cómo se sube una versión nueva y cuánto tarda? ¿Se puede revertir?
Pruebas y monitoreo	¿Algo avisa cuando se rompe, o se enteran los usuarios primero?

Ninguna de estas preguntas se responde mirando el producto desde afuera. Se responden leyendo el repositorio, entrando a las cuentas de los servicios y publicando una versión de prueba para ver qué tan difícil es. Esa última parte es la que más información da: si en los primeros días nadie consigue publicar un cambio mínimo, eso ya es un hallazgo.

El recorrido completo, en el orden en que ocurre:

Nota que la última caja es tuya. La auditoría no decide: ordena la información para que decidas tú, incluyendo la opción de no seguir con quien la hizo.

Qué dice el veredicto escrito

El entregable tiene que ser un documento, no una llamada. Tiene que poder leerse sin quien lo escribió delante, porque su utilidad real aparece después: cuando se lo enseñas a un socio, a un inversionista o al siguiente proveedor que cotice el trabajo.

Pide que tenga estas cuatro partes:

1. Estado general, en una página. Qué es el producto, en qué está construido, qué tan sano está y cuál es la recomendación principal. Escrito para que lo entienda alguien que no programa, porque esa persona suele ser quien firma.

2. Riesgos, ordenados por urgencia. Cada uno con lo que puede pasar si no se atiende y cuánto trabajo cuesta atenderlo. Ordenados por daño potencial, no por dificultad técnica. Lo que puede tumbar el producto o exponer datos va arriba, aunque se arregle en una tarde.

3. Conservar, reparar o reescribir, parte por parte. El veredicto no es un juicio único sobre “el código”. Es una lista: esta parte está bien y se queda, esta funciona pero hay que repararla antes de crecer, esta conviene rehacerla y esta otra se puede reemplazar por un servicio que ya existe.

4. Cuánto cuesta sostenerlo desde aquí. La suma de lo que pagas cada mes en servicios, más una estimación del trabajo de mantenimiento que el producto va a pedir tal como está. Es el número que casi nunca alguien te dio antes y el que más pesa al decidir.

Lo que el documento no debería tener: adjetivos sobre el trabajo de quien vino antes. El código anterior se hizo con el tiempo, el presupuesto y la información que había en ese momento, y quien audita no los conoce. El veredicto describe el estado y el costo, no reparte culpas.

Cuánto dura una auditoría y qué pasa después

Una semana, para un producto de tamaño normal. Es tiempo suficiente porque el alcance está acotado: leer, probar, publicar algo mínimo y escribir. No incluye arreglar nada, y conviene dejar eso por escrito antes de empezar. Si en el camino aparece algo crítico —una llave expuesta, datos sin respaldo— eso se avisa el mismo día, no se guarda para el informe.

Sobre el precio, un solo consejo: desconfía de quien cobre la auditoría en función del tamaño del problema que encuentre. Cuando el pago crece con la gravedad del diagnóstico, el diagnóstico deja de ser confiable.

Después del informe hay tres caminos, y los tres están bien:

• Sigues con tu equipo. Te llevas el documento y lo ejecutas con quien ya tienes. Es el resultado más común cuando el producto está sano y lo que faltaba era claridad.
• Alguien se hace cargo del producto de forma continua. Mantenimiento, publicaciones, funcionalidades nuevas y un roadmap en lenguaje claro, con una llamada fija cada semana. Es un acuerdo mensual, no un proyecto cerrado; en cómo trabajo describo cómo se ve una semana así.
• No sigues con ese producto. A veces el veredicto es que reconstruir cuesta menos que sostener, o que el producto ya no responde a lo que hace tu negocio hoy. Saberlo en una semana es mucho mejor que descubrirlo en seis meses.

La recomendación más común después de una auditoría no es reescribir. Es conservar el núcleo, reparar tres cosas concretas y recién entonces volver a construir encima.

Conservar, reparar o reescribir: cómo se decide

“Está muy mal, hay que hacerlo de nuevo” es la primera reacción de casi cualquier desarrollador frente a código ajeno. A veces es cierta. Muchas veces significa que leer el trabajo de otro es incómodo y empezar de cero es más entretenido, y quien paga esa preferencia eres tú.

Los criterios, parte por parte:

Lo que encuentro	Qué hago
Funciona, se entiende y se puede modificar sin miedo	Se conserva, aunque no esté escrito como lo habrías escrito tú
Funciona, pero cada cambio toma el triple de lo que debería	Se repara: se ordena esa parte antes de construir encima
Resuelve algo que hoy compras hecho y barato	Se reemplaza por ese servicio
Está sobre una tecnología que ya no recibe actualizaciones	Se migra, con fecha, aunque hoy funcione
Nadie entiende qué hace y nadie se atreve a tocarlo	Se aísla primero, se reescribe después, por partes
El producto entero es más chico que el costo de entenderlo	Se reescribe, y es la única vez que reescribir sale barato

La regla de fondo: reescribir se justifica por el costo de seguir, nunca por el gusto. Y cuando se justifica, casi nunca es todo a la vez. Se reescribe una parte, se publica, se comprueba que los usuarios siguen ahí y se pasa a la siguiente. Una reescritura total significa meses sin nada nuevo para tus usuarios mientras el producto viejo, el que sí genera ingresos, deja de recibir atención.

Si tu producto es una app móvil o tiene un componente de IA, el criterio no cambia pero lo que se revisa sí: en apps móviles y productos con IA detallo qué mira cada uno.

Las señales de alarma más frecuentes

Estas aparecen tanto que conviene que las revises tú mismo, hoy, aunque no contrates a nadie:

1. Las cuentas no están a tu nombre. El dominio, la cuenta de la tienda de aplicaciones, el servidor o el servicio de correo siguen registrados con el correo del proveedor anterior. Mientras eso sea así, tu producto no es del todo tuyo.
2. Hay una sola llave y la conoce todo el mundo. Un único acceso con permisos totales, compartido por mensaje, sin forma de saber quién hizo qué ni de revocarlo a una sola persona.
3. No hay copias de respaldo, o nadie las ha restaurado nunca. Una copia que jamás se probó no es una copia de respaldo. Es una suposición.
4. Nadie sabe cómo publicar una versión. Si la única persona que sabía subir un cambio se fue, tu producto está congelado aunque el código esté intacto.
5. Las dependencias llevan años sin actualizarse. El software que tu producto usa por debajo recibe correcciones de seguridad. Cuando no se aplican durante años, actualizarlas deja de ser rutina y se vuelve un proyecto.
6. Los datos personales de tus usuarios están donde no deberían. Copias completas de la base de datos en la computadora de alguien, datos sensibles sin cifrar, registros que guardan más de lo necesario.
7. No hay ningún entorno de prueba. Cada cambio se prueba directamente sobre lo que usan tus clientes.

Las tres primeras se resuelven en días, sin tocar una línea de código, y son las que más riesgo quitan. Si de todo este artículo solo haces una cosa, revisa a nombre de quién están tus cuentas.

Qué hay que reunir antes de empezar

Quien lea tu producto va a pedir esto, sea quien sea. Reunirlo de antemano te ahorra la primera semana:

• El código. Acceso de lectura al repositorio, con su historial. Si no hay repositorio y solo existe el código subido al servidor, también se puede, y ese dato ya es parte del diagnóstico.
• Las cuentas de los servicios. Dónde está publicado, qué base de datos usa, qué servicios de terceros paga. No hacen falta las contraseñas del dueño: un acceso de lectura propio alcanza y es más seguro.
• Las tiendas, si hay app. Acceso a la cuenta de App Store y Google Play, aunque sea en el rol más limitado.
• Lo que exista de documentación o contratos. Aunque esté desactualizado. El contrato con el proveedor anterior sirve sobre todo para saber qué dice sobre la propiedad del código.
• Una conversación de una hora con quien conoce el negocio. Qué hace el producto para la empresa, qué duele hoy y qué tiene que pasar en los próximos seis meses. Sin eso, la auditoría evalúa el código contra un ideal abstracto en lugar de contra tu realidad.

Si no tienes varias de estas cosas, no es un impedimento para empezar: recuperar los accesos suele ser la primera tarea del plan, y es exactamente el tipo de problema que conviene descubrir ahora. Si el rol que hay detrás de este trabajo te resulta nuevo, en qué es un ingeniero de producto explico de qué se hace cargo esa persona más allá de escribir código.

Preguntas frecuentes

¿Cuánto cuesta una auditoría de código?

Depende del tamaño del producto y de quién la haga; lo habitual es cobrarla por hora sobre un alcance de una semana, acordado antes de empezar. El punto de comparación útil no es cero: es lo que cuesta un mes de desarrollo a ciegas, porque la alternativa a auditar no es ahorrar ese dinero, sino gastarlo construyendo sobre algo que nadie entendió.

¿Puedo pedir una auditoría si no tengo acceso al repositorio?

Sí, y es un caso frecuente. Se empieza por recuperar los accesos, que suele ser una gestión con el proveedor anterior o con las plataformas donde están registradas las cuentas. Mientras eso avanza se puede revisar lo que sí es visible desde afuera: el producto en uso, las apps publicadas, los dominios y a nombre de quién está cada cosa. Si al final el código resulta irrecuperable, eso también es un veredicto, y es mejor tenerlo antes de planificar el año.

¿Conviene reescribir el producto desde cero?

Casi nunca, y menos de lo que suele recomendarse. Reescribir significa meses sin novedades para tus usuarios mientras alguien reconstruye funcionalidad que ya existía, con el riesgo de perder detalles que nadie documentó y que solo el código viejo conocía. Se justifica cuando sostener lo que hay cuesta más que rehacerlo, cuando la tecnología de base ya no recibe actualizaciones o cuando el producto es tan pequeño que entenderlo cuesta más que escribirlo. Aun entonces se hace por partes, publicando cada una.

¿La auditoría sirve si quiero seguir con mi equipo actual?

Sí, y es un uso legítimo del documento. El veredicto describe el estado, el costo y las prioridades; quién ejecute ese plan es otra decisión. Sirve para ordenar el trabajo con el equipo que ya tienes, o para comparar cotizaciones sobre una base común en lugar de sobre descripciones vagas. Por eso el documento tiene que estar escrito para que se lea sin quien lo hizo.

¿Qué pasa si el veredicto dice que el producto no sirve?

Un buen informe te lo dice con el detalle de por qué, y con el costo de las dos alternativas: sostener lo que hay o reconstruirlo. Es la conversación incómoda del trabajo y es justamente la que estás pagando. Un diagnóstico que siempre termina en “esto se puede arreglar, contrátame” no es un diagnóstico, así que pregunta de antemano qué pasa si la respuesta es la otra.

Conclusión

Un producto heredado no es un problema técnico, es un problema de información: estás tomando decisiones de dinero sobre algo que nadie de tu lado ha leído. Una auditoría convierte eso en un documento con riesgos ordenados, un costo mensual real y una recomendación parte por parte, en una semana de trabajo.

Si acabas de quedar a cargo de un producto, hazlo en este orden: primero revisa a nombre de quién están el dominio, las cuentas y las tiendas, porque eso se arregla en días y es lo que más riesgo quita; después consigue acceso de lectura al código y a los servicios, aunque todavía no sepas qué hacer con ellos; recién entonces pide la auditoría, y no comprometas funcionalidades nuevas ni fechas con tus clientes hasta tenerla en la mano. Y cuando alguien te proponga reescribir todo antes de haber leído lo que hay, pídele el costo de la otra opción.