La due diligence técnica para la que nadie se prepara

Durante mi etapa como CTO en OneRagtime, lideré las due diligences técnicas de las startups en el deal flow. El fondo filtraba más de 4.000 deals al año, y para los que pasaban los primeros filtros, alguien tenía que mirar bajo el capó. Ese alguien solía ser yo.

Tras auditar decenas de empresas, aparecieron patrones. Los problemas técnicos que mataban deals rara vez eran los que los fundadores esperaban. Y las cosas que impresionaban a los inversores eran a menudo las partes más mundanas de la stack.

Esto es lo que aprendí.

Lo que los inversores realmente miran

A los inversores no les importa tu elección de framework. No les importa si usas React o Vue, Python o Node, AWS o GCP. Son detalles de implementación. Lo que les importa es si tu base técnica puede soportar el negocio que intentas construir.

Las tres preguntas que guían cada due diligence técnica son simples. ¿Puede este equipo entregar lo suficientemente rápido para alcanzar sus milestones? ¿Escalará la tecnología con el negocio? ¿Hay riesgos ocultos que puedan explotar después de invertir?

Todo lo demás, las herramientas específicas, los patrones de arquitectura, el estilo de código, se evalúa a través del prisma de esas tres preguntas.

Las señales de alarma que matan deals

Sin tests, sin CI/CD. Esta es la señal de alarma más común, y casi siempre es motivo de descarte. Si una startup no tiene tests automatizados ni pipeline de integración continua, me dice dos cosas: no pueden entregar con confianza y están acumulando riesgo con cada despliegue. He visto startups con código precioso pero cero tests. Da igual lo limpio que sea tu código si no puedes verificar que funciona después de cada cambio.

Punto único de fallo en el equipo. Si una persona escribió el 90 % del código y esa persona es el fundador, ¿qué pasa cuando hay que contratar? ¿Qué pasa si esa persona enferma? Siempre pregunto: "Si tu lead developer se fuera mañana, ¿cuánto tardaría el equipo en entregar una funcionalidad de forma autónoma?" La respuesta me dice todo sobre la distribución del conocimiento y la documentación.

Sin separación de entornos. Las startups que despliegan directamente a producción sin entorno de staging están jugando con fuego. He visto equipos que testean en producción porque "es más rápido." Es más rápido hasta que no lo es. Un mal despliegue en una base de datos de producción y estás explicando una pérdida de datos a tus usuarios.

La conversación del "rewrite". Cuando los fundadores me dicen que necesitan reescribir toda su codebase, me pongo nervioso. A veces un rewrite es genuinamente necesario. Pero más a menudo, significa que el equipo tomó malas decisiones arquitectónicas pronto y nunca las abordó de forma incremental. Un equipo que no puede refactorizar incrementalmente es un equipo que se enfrentará al mismo problema después del rewrite.

El sobre-engineering. Este sorprende a la gente. He descartado deals porque una startup de cinco personas tenía una arquitectura de microservicios con doce servicios, un cluster de Kubernetes y una cola de mensajes, todo sirviendo a unos pocos cientos de usuarios. Esto me dice que el equipo optimiza para la elegancia técnica por encima del impacto de negocio. También significa que sus costes de infraestructura son probablemente diez veces lo que deberían ser.

Lo que impresiona a los inversores

Pipelines de despliegue limpios. Un equipo que puede desplegar a producción múltiples veces al día con confianza es un equipo que puede iterar rápido. En OneRagtime, las startups que más me impresionaron tenían pipelines de CI/CD simples y fiables. No complejos. Solo pipelines que funcionaban siempre.

Monitoring y alertas. Cuando pregunto a un fundador "¿cómo sabes cuándo algo se rompe?" y me muestra un dashboard con métricas reales y umbrales de alerta, sé que se toman la fiabilidad en serio. La mayoría de las startups en early-stage no tienen ningún monitoring. Se enteran de las caídas cuando los usuarios se quejan.

Documentación de decisiones. No documentación de código, aunque eso ayuda. Me refiero a registros de por qué el equipo tomó las decisiones que tomó. ADR (Architecture Decision Records) o incluso un simple documento que diga "elegimos PostgreSQL porque X, lo reconsideraremos cuando Y" me muestra un equipo que piensa deliberadamente sobre su dirección técnica.

Calidad del modelo de datos. El esquema de base de datos me dice más sobre la madurez técnica de una startup que cualquier otro artefacto. Estructuras de tablas limpias, indexación correcta, relaciones claras entre entidades y sin problemas obvios de normalización. Cuando veo un modelo de datos bien diseñado en una startup early-stage, sé que el lead técnico entiende lo que importa.

Honestidad sobre la deuda técnica. Toda startup tiene deuda técnica. Las que me impresionan son las que pueden señalarla y explicar el compromiso. "Tomamos este atajo porque necesitábamos entregar antes del Q3. Aquí está nuestro plan para abordarlo." Eso es mil veces mejor que "nuestro código es perfecto" o un fundador que no sabe dónde está la deuda.

Los patrones de los que nadie habla

Algunos patrones solo se hacen visibles después de ver suficientes empresas.

La velocidad del equipo importa más que la calidad del código. Un equipo que entrega funcionalidades cada semana con código desordenado superará a un equipo que entrega mensualmente con código limpio. La calidad del código importa, pero solo en la medida en que afecta la capacidad del equipo para seguir entregando. He invertido en startups con codebases feas que avanzaban rápido y generaban ingresos. He pasado de startups con código precioso que estaban atascadas en parálisis por análisis.

La profundidad técnica del fundador fija el techo. Incluso en startups donde el fundador es "no técnico", las más exitosas tienen un cofundador o contratación temprana que realmente entiende el diseño de sistemas. Cuando audito una startup y el lead técnico no puede explicar su propia arquitectura con claridad, es una señal de un problema que solo empeorará a medida que el equipo crezca.

Los costes de infraestructura revelan prioridades. Siempre pido ver la factura de cloud. No porque me importe la cifra exacta, sino porque me muestra dónde está gastando el equipo. Una startup que quema miles al mes en infraestructura sirviendo a cientos de usuarios tiene un problema de disciplina de costes. Una startup que funciona con poco y asignación inteligente de recursos me demuestra que entienden que el dinero es finito.

Cómo prepararte

Si eres fundador preparándote para una due diligence técnica, esto es lo que yo haría.

Primero, asegúrate de que puedes desplegar con confianza. Monta CI/CD si aún no lo tienes. Escribe tests para tus caminos críticos. Esto no es opcional. Es la expectativa mínima.

Segundo, conoce tu arquitectura. Sé capaz de dibujarla en una pizarra y explicar por qué existe cada componente. Conoce los compromisos que tomaste y cuáles harías diferente hoy.

Tercero, ten tus métricas preparadas. ¿Cuántos despliegues por semana? ¿Cuál es tu uptime? ¿Cuánto tarda en incorporarse un nuevo desarrollador? Estos números cuentan la historia de tu cultura de ingeniería mejor que cualquier presentación.

Cuarto, sé honesto sobre tu deuda. Todo auditor sabe que la tienes. Intentar esconderla es peor que tenerla. Muéstrame que sabes dónde está y que tienes un plan.

La visión general

La due diligence técnica no se trata solo de encontrar problemas. Se trata de entender si un equipo tiene la cultura de ingeniería para tener éxito. Las mejores startups que audité no eran las que tenían la tecnología más sofisticada. Eran aquellas donde el equipo entregaba consistentemente, comunicaba con claridad sus compromisos y construía sistemas que coincidían con las necesidades reales de su negocio.

Eso es lo que busco. Y es lo que intento construir en cada equipo que lidero.