Revisión técnica antes de levantar inversión: qué miran
Qué revisa un due diligence técnico antes de que entre un inversionista: propiedad del código, seguridad, escalabilidad, equipo y cómo prepararte.
Read in English →
En una revisión técnica (due diligence técnico), los inversionistas comprueban si la empresa es realmente dueña de su código, si el producto es seguro, si puede crecer sin reescribirse y si el equipo puede seguir entregando. Miran el código, la infraestructura y las personas, y buscan riesgos que cambiarían el precio o el acuerdo, no un código perfecto.
En esta guía verás qué se revisa normalmente en cada etapa, las preguntas que te van a hacer, las señales de alerta que más pesan en apps hechas con herramientas de IA y cómo prepararte en las semanas previas.
¿Cuándo ocurre la revisión técnica?
Depende de la ronda y del inversionista. En pre-seed y seed suele ser una conversación con un socio o asesor técnico, una demo y un vistazo al repositorio. En rondas posteriores, o en una adquisición, puede ser una revisión formal hecha por una firma externa con acceso al código, la documentación y el equipo.
En los dos casos las preguntas se parecen. Lo que cambia es la profundidad.
¿Qué miran los inversionistas?
Propiedad del código
- ¿El repositorio es de la empresa, o está en la cuenta personal de un fundador o un contratista?
- ¿Todos los que escribieron código (socios, empleados, freelancers, agencias) firmaron un acuerdo que lo cede a la empresa?
- ¿Qué componentes de terceros y de código abierto se usan, y con qué licencias?
En apps hechas con herramientas de IA, espera la pregunta de cuánto código se generó y cómo se revisó. Nuestra explicación sobre quién es dueño del código hecho con IA da el contexto. La propiedad es tanto un tema legal como técnico, así que pide a un abogado que revise tus acuerdos; esta guía no es asesoría legal.
Seguridad
- ¿Los secretos están fuera del código y del frontend?
- ¿El acceso a los datos se valida en el servidor, para que un cliente no pueda leer los de otro?
- ¿Los datos personales se manejan de acuerdo con la política de privacidad y las leyes que aplican?
- ¿Hubo algún incidente de seguridad, y cómo se manejó?
Los revisores suelen usar una referencia reconocida como el OWASP Top 10. Mira nuestra guía del OWASP Top 10 para apps hechas con IA.
Arquitectura y escalabilidad
- ¿El sistema aguanta el crecimiento del plan de negocio sin rehacerse?
- ¿Hay cuellos de botella evidentes: un solo servidor, consultas lentas, una API de terceros con límites estrechos?
- ¿Cuánto depende el producto de un solo proveedor, y qué tan difícil sería moverse?
Calidad del código y proceso
- ¿El código está en control de versiones con un historial entendible?
- ¿Hay pruebas automáticas para los flujos críticos?
- ¿Cómo llega el código a producción, y se puede volver atrás una versión mala?
- ¿Cuánta deuda técnica hay, y está identificada y registrada?
Equipo y conocimiento
- ¿Quién entiende el sistema, y qué pasa si esa persona se va?
- ¿Existe documentación que un ingeniero nuevo pueda usar?
- ¿Cómo es el plan de contratación técnica, y es realista?
Costos
- ¿Cuánto cuesta hoy la infraestructura y cómo va a crecer con los usuarios?
- ¿Hay costos grandes o poco comunes, como el uso de modelos de IA, que crecen más rápido que los ingresos?
¿Qué señales de alerta aparecen en apps hechas con IA?
Estos son los temas que suelen cambiar la conversación con un inversionista:
- Código o cuentas a nombre de personas. El dominio, la base de datos o el repositorio están en la cuenta personal de un fundador o de un freelancer.
- Datos sin protección. Tablas sin políticas de acceso, o permisos que solo se validan en el navegador.
- Secretos en el frontend. Claves de servicios pagos o de acceso de administrador visibles en el código publicado.
- Sin separación entre pruebas y producción. Datos reales de clientes mezclados con experimentos.
- Nadie sabe explicar el código. La app se hizo a puro prompt y nadie del equipo puede contar cómo funciona una función.
- Sin salida de la herramienta. El producto no puede funcionar fuera del constructor con el que se hizo.
Ninguna de estas, por sí sola, tiene por qué tumbar un acuerdo. Lo que importa es que las conozcas y tengas un plan.
¿Cómo te preparas?
Empieza unas semanas antes de que lleguen las preguntas:
- Ordena la propiedad. Pasa el repositorio, el dominio y las cuentas de servicios a nombre de la empresa, y junta las cesiones firmadas de todos los que aportaron.
- Haz tu propia revisión primero. Una revisión independiente de código y seguridad te permite corregir lo peor, o al menos explicarlo, antes de que lo encuentre un inversionista.
- Corrige lo crítico. Claves expuestas, políticas faltantes en la base de datos y respaldos inexistentes suelen arreglarse rápido y se ven muy mal si siguen ahí.
- Escribe el resumen. Un documento corto de arquitectura, una lista de servicios con sus costos y cómo funciona el despliegue. Mira cómo documentar tu app para entregarla.
- Arma una carpeta para el data room. Resumen de arquitectura, lista de dependencias y licencias, medidas de seguridad, historial de incidentes, costos de infraestructura y la hoja de ruta técnica.
- Sé honesto con la deuda. Una lista clara de problemas conocidos con un plan para resolverlos da más confianza que decir que no hay ninguno.
Respuestas rápidas
¿Los inversionistas de etapa seed de verdad miran el código? Algunos sí y otros no. Muchos al menos preguntan quién lo hizo, de quién es y en qué corre.
¿Usar herramientas de IA baja mi valoración? Usar IA no es un problema en sí. Sí lo son el código que nadie entiende, los huecos de seguridad y la propiedad poco clara.
¿Conviene hacer mi propia revisión técnica antes de levantar? Suele valer la pena, porque arreglas los problemas a tu ritmo y no en medio de la negociación.
¿Qué documentos debo tener listos? Un resumen de arquitectura, la lista de servicios y costos, los acuerdos de cesión de propiedad intelectual, la información de licencias de código abierto y un resumen de seguridad.
¿Te estás preparando para levantar?
Nuestra App Rescue Audit (USD 299) es la revisión de tu código por un ingeniero senior, con informe escrito en 2 días hábiles: un buen punto de partida antes de que miren los inversionistas. Puedes empezar con el chequeo gratuito de tu app, y si la revisión deja trabajo pendiente, te ayudamos con mantenimiento de software o desarrollo de MVP. Escríbenos para conversarlo.


