La respuesta corta
Una due diligence técnica de una app no va de leer código. Va de responder tres preguntas que deciden el precio:
- ¿La empresa es dueña de lo que cree que es dueña?
- ¿Se puede seguir construyendo encima, o hay que rehacerlo?
- ¿Qué pasa si mañana no está la persona que la escribió?
Todo lo demás —métricas de cobertura, arquitectura, elegancia— es secundario frente a esas tres. Un producto con código mediocre y propiedad limpia es comprable. Un producto con código excelente cuya cuenta de desarrollador está a nombre de un proveedor externo, no lo es al mismo precio.
1 · Propiedad: lo que hay que ver, no lo que te cuenten
Este bloque se resuelve con capturas de pantalla, no con conversaciones. Pide ver, en pantalla compartida:
- La cuenta de Apple Developer y la de Google Play: a nombre de quién están y quién es el Account Holder. Si el titular es la agencia, no estás comprando la app: estás comprando el derecho a negociar con la agencia.
- El repositorio: en la organización de quién, con qué histórico y quién tiene permisos de administración.
- Las llaves de firma: dónde están, quién las tiene, si hay Play App Signing. El detalle de por qué esto decide tanto está en quién debe custodiar los certificados de firma.
- Los dominios, los DNS y los certificados TLS: mismo criterio.
- Las cuentas de los servicios de terceros: analítica, notificaciones, crash reporting, pasarela de pago. Registradas con correos corporativos o con el Gmail personal de alguien que ya no está.
Si algo de esto está a nombre de un proveedor, hay que valorar el coste del traspaso — y el traspaso de una app en producción no es gratis ni instantáneo: está detallado en qué se rompe al transferir una app a otra cuenta.
2 · Contratos y licencias
- Cesión de propiedad intelectual por escrito de todos los que han tocado el código: empleados, freelances y proveedores. La cesión no se presume.
- Licencias de las dependencias. Un inventario generado automáticamente, no una afirmación. Lo que importa no es el número de dependencias, sino si hay alguna copyleft fuerte incrustada en el producto.
- Assets con licencia: tipografías, iconos, fotografía, música. Es donde aparecen los problemas más tontos y más caros.
- Contratos con el proveedor actual: quién puede rescindir, con qué preaviso, y qué obligaciones de traspaso hay escritas. Si no hay ninguna, esa es la respuesta.
3 · Continuidad: el factor autobús
- ¿Cuántas personas pueden compilar y publicar la app hoy? Si la respuesta es una, ese es el riesgo principal del activo, por encima de cualquier deuda técnica.
- ¿Está documentado el proceso de release? No "existe documentación", sino: alguien nuevo, siguiendo el documento, ¿publica?
- ¿Hay entorno de desarrollo reproducible? Clonar el repositorio y llegar a una build en un día es la prueba. Si necesita configuración que solo tiene una persona en su portátil, el proyecto tiene una dependencia humana disfrazada de dependencia técnica.
- ¿Los secretos están en un gestor de secretos o repartidos en ficheros locales y variables de entorno de tres máquinas distintas?
4 · El estado real del producto
Aquí sí se mira el código, pero buscando cosas concretas:
- Actualidad de la plataforma. Qué versiones mínimas de iOS y Android soporta, en qué versión de SDK está y cuánto le falta para chocar con el próximo requisito obligatorio de las tiendas. Un proyecto que va dos ciclos por detrás tiene un trabajo obligatorio ya devengado.
- Dependencias abandonadas. No cuántas hay, sino cuántas están sin mantenimiento y en el camino crítico.
- Qué pasa cuando falla. ¿Hay crash reporting? ¿Alguien lo mira? Una app sin observabilidad no tiene métricas de calidad: tiene opiniones.
- Qué está probado. Más que el porcentaje de cobertura, qué partes del flujo de dinero o de datos sensibles tienen pruebas.
- Deuda declarada frente a deuda descubierta. Pregunta al equipo qué reescribirían. Si te contestan rápido y con detalle, son conscientes y eso es buena señal. Si dicen que está todo bien, hay que mirar más.
5 · Seguridad y cumplimiento
- Dónde viven los datos personales y bajo qué base legal.
- Si hay datos de salud, de pago o de menores, qué régimen aplica.
- Si la app entra en entornos corporativos, qué exige el cliente: identidad federada, gestión de dispositivo, política de protección de aplicaciones. Está desarrollado en SSO corporativo en una app móvil y en los requisitos de MDM e Intune.
- Si alguna vez ha habido un incidente, y qué se hizo.
Lo que te van a enseñar y lo que tienes que pedir
| Te enseñan | Pide |
|---|---|
| Un diagrama de arquitectura | Un clon del repositorio y una build reproducible |
| «Tenemos tests» | Qué cubren exactamente los del flujo de pago |
| «El código es nuestro» | El contrato de cesión firmado |
| «Está todo en la nube» | Quién es el titular de cada cuenta |
| Métricas de descargas | Retención y crashes de las últimas cuatro versiones |
El entregable
Una due diligence útil termina en tres listas, no en un informe de cincuenta páginas:
- Bloqueantes: cosas que hay que resolver antes de firmar. Casi siempre son de propiedad, no de código.
- Coste devengado: trabajo obligatorio que el comprador heredará —actualizaciones de plataforma, dependencias muertas, migraciones pendientes— con su estimación.
- Riesgos con plan: lo que no bloquea pero hay que vigilar, con quién y cuándo.
Esas tres listas se pueden llevar a una negociación. Un informe genérico, no.
Cuándo no hace falta
Si lo que se compra es el equipo y no el producto —un acquihire— casi todo lo anterior sobra: lo que importa entonces son las cesiones de propiedad intelectual y los pactos de no competencia. Y si el producto se va a reescribir de todas formas, la due diligence se reduce a propiedad, datos y contratos.
Nosotros hacemos este trabajo como auditoría técnica de app móvil, y cuando hace falta criterio técnico sostenido en la mesa de negociación, como CTO as a Service.
