Source code escrow: por qué a la mayoría de los founders no técnicos les venden la defensa equivocada

El source code escrow fue diseñado para compradores corporativos averses al riesgo que se protegen de proveedores grandes que pueden quebrar. Es el instrumento equivocado para una startup early-stage que está comprando software a medida de un estudio pequeño. La protección correcta no cuesta nada y depende de que tres cosas estén en su lugar desde el primer día.

La founder deslizó el PDF marcado sobre la mesa. Su abogado había resaltado en amarillo una cláusula nueva y había anotado “agregada según práctica estándar” en el margen. La cláusula era un acuerdo de source code escrow de tres páginas, adjunto como Exhibit C al contrato que ella estaba a punto de firmar con un estudio de tres personas que construía su producto seed-stage. “Dice que necesitamos esto por si el estudio cierra”, contó. “¿Lo necesitamos?”

El abogado la estaba protegiendo de un riesgo que no existe en su situación. El estudio que iba a contratar no estaba quebrando en ningún sentido que la cláusula de escrow contemplara. Lo que ella realmente temía, aquello contra lo que quería protección, era otra cosa. Solo que no sabía cómo nombrarlo, y su abogado echó mano del único instrumento del que tenía un template.

Esto pasa todo el tiempo. Una founder no técnica cierra una ronda seed. Empieza la negociación del contrato del primer build serio del producto. Su abogado agrega source code escrow como “protección estándar”. El estudio acepta porque quiere cerrar el deal. Seis meses después el contrato está firmado, los depósitos se hacen en la agenda acordada, y nada de eso hace lo que la founder pensó que haría.

Este artículo es para esa founder.

Qué es source code escrow

Source code escrow es un acuerdo legal de tres partes en el que un proveedor de software deposita una copia del código fuente, los scripts de build y la documentación de soporte con un agente externo neutral. El agente custodia el depósito. Si ocurren ciertas condiciones de release predefinidas, normalmente el proveedor entrando en quiebra, dejando de dar soporte al producto o incumpliendo una obligación material en el contrato de licencia, el agente entrega el depósito al cliente. Hasta ese evento gatillo, el cliente no tiene acceso al código.

Ese es el modelo estándar. Tres partes: el depositante (el proveedor), el beneficiario (el cliente) y el agente (una firma especializada como Escode de Iron Mountain o NCC Group, más jugadores más pequeños). Un depósito, refrescado periódicamente. Una lista cerrada y estrecha de condiciones de release. Un juego de espera.

Es un instrumento legal, no técnico. La mecánica que importa vive dentro de cláusulas contractuales, no dentro del codebase.

Por qué existe el source code escrow

El instrumento fue diseñado para un problema empresarial. En los años 80 y 90, una empresa Fortune 500 licenciaba un paquete de software crítico para el negocio, normalmente corriendo sobre mainframe, de un único proveedor cuya supervivencia era incierta. El comprador no tenía forma realista de cambiar de proveedor a mitad de camino. Si el proveedor desaparecía, el comprador quedaba con un binario que ya no podía mantener, modificar ni correr en hardware nuevo. El source code escrow fue la respuesta legal: el licenciatario pagaba una prima pequeña para saber que, si el proveedor desaparecía, el código fuente afloraría.

Ese problema sigue existiendo, en una forma más estrecha, para empresas grandes que licencian software empaquetado de proveedores medianos. No existe para una startup early-stage que compra software a medida a un estudio de cinco personas. Las dos situaciones se parecen en la superficie (alguien está construyendo software para mí, ¿qué pasa si desaparece?) pero el instrumento legal sirve solo para la primera.

Cuando una SaaS Series B licencia un software de payroll de un proveedor regional, escrow es razonable. Cuando una founder seed-stage contrata un estudio para construir su producto desde cero, escrow es la herramienta equivocada. El proveedor no le está licenciando software. Al proveedor le pagan para construir software que es de ella desde el momento en que se escribe, o al menos debería serlo.

El instrumento se metió en el contexto equivocado porque los templates de contrato viajan más rápido que el razonamiento detrás de ellos.

Los tres problemas que los founders no técnicos creen que escrow resuelve

Cuando un founder me pregunta por agregar escrow a un contrato de software a medida, la ansiedad de fondo es casi siempre una de estas tres:

“¿Y si el estudio cierra?” El miedo es que un estudio de cinco personas quiebre, un ingeniero clave se vaya, los founders pivoteen a consultoría, y el codebase se vaya con ellos. Este riesgo es real. Es la versión más común de la pregunta.

“¿Y si se niegan a entregar el código?” El miedo es que la relación se rompa, el founder deje de pagar, el estudio invoque alguna cláusula y se quede con el trabajo. También es real, especialmente con proveedores que cobran por milestone y no por ownership.

“¿Y si mi único dev renuncia?” Esta es la pregunta del bus factor con otra ropa. El contrato está firmado con un estudio pero el build depende funcionalmente de un ingeniero adentro de ese estudio.

Ahora mirá lo que hace escrow. Libera un depósito si un proveedor entra en quiebra o cesa formalmente el soporte del producto. El primer escenario, estudio que cierra, a veces califica para release si podés demostrar quiebra en un sentido legal definido. El segundo y el tercero, no. Una disputa de relación no es un release event. Un dev solo que se va no es un release event. Para cuando la founder descubre su problema real, la cuenta de escrow está sentada llena de un depósito que no puede sacar.

Hay también un problema más silencioso. Las release conditions de un contrato típico de escrow están redactadas de forma estrecha para proteger al proveedor de releases frívolos. Se espera que el agente verifique que el trigger efectivamente ocurrió, lo que puede tomar semanas. En el timeline de una startup, ese solo retraso puede ser fatal.

Qué hace de verdad el source code escrow, y qué no

El depósito es lo que el proveedor decida depositar, en el cronograma que el contrato especifique. El agente de escrow, por default, no verifica que el depósito sea un build funcional. Algunos agentes ofrecen un servicio de verificación por una tarifa adicional. La mayoría de los contratos se saltea ese paso.

Así que lo que está en la bóveda, seis meses después, suele ser una carpeta zipeada. Puede contener el código de producción más reciente, o una copia de seis semanas atrás, o un build que no compila. El contrato estándar de escrow protege contra el proveedor que se niega a depositar cualquier cosa, pero no contra el proveedor que deposita algo inservible.

El release entrega código, no contexto. No hay diagramas, no hay notas de arquitectura, no hay documentación de onboarding, no hay variables de entorno, no hay secrets de producción, no hay scripts de deploy. La bóveda contiene código fuente. El código fuente no es un sistema. Un equipo de tres ingenieros que reciben un repo limpio sin documentación y sin continuidad de memoria está mirando un codebase desconocido, no un producto en producción que pueda seguir operando.

Esa es la distancia entre lo que los founders piensan que escrow hace y lo que de verdad hace. Escrow te protege del proveedor que se niega a darte un snapshot. No te protege de heredar un snapshot que no se puede deployar, modificar ni entender sin el equipo que lo construyó.

Lo que realmente necesitás en su lugar

Para una startup early-stage que compra software a medida, cuatro cosas en su lugar desde el primer día vuelven al escrow innecesario.

1. El repositorio vivo es tuyo, no un snapshot en una bóveda. El repo vive en una organización de GitHub o GitLab que pertenece a la empresa de la founder, no al estudio. Los ingenieros del estudio están agregados como collaborators con permiso de commit. Cada push queda en tu cuenta, en tiempo real, con el historial completo. Si el estudio se va mañana, vos tenés lo que la bóveda de escrow eventualmente entregaría, salvo que lo tenés ahora, con historial completo, totalmente buildable, sin agente al que llamar y sin release event que probar.

Esta es la protección aislada de mayor palanca que una founder no técnica puede dejar en su lugar y cuesta cero. La mayoría de los estudios la aceptan sin negociar si la pedís antes de que arranque el build. Los que se niegan te están diciendo algo útil.

2. Cesión de IP limpia, vinculada al pago. El contrato cede la propiedad intelectual de los entregables a la empresa de la founder al momento del pago, no al momento de la conclusión del proyecto. Cada factura pagada transfiere el ownership del trabajo hecho hasta ese punto. No hay cláusula de “cederemos al cerrar el proyecto”, porque el cierre del proyecto es un blanco móvil y la palanca del estudio durante una disputa es exactamente el gap entre lo entregado y el IP cedido.

Una buena estructura de contrato para un build de software a medida resuelve esto en un solo párrafo. Una mala demora la cesión y crea exactamente la palanca que empuja a los founders a buscar escrow como backup.

3. Documentación de onboarding que sobreviva al equipo. El entregable no es solo código. Es un README que lleva a un ingeniero nuevo a correr el sistema localmente en menos de treinta minutos, un diagrama de arquitectura de una página, una lista de cada servicio de terceros del que depende el sistema con contacto y billing seat de cada uno, y un inventario de variables de entorno. Nada de esto es exótico. Todo estudio que construye cosas para durar lo produce. Los estudios que se resisten a producirlo no están interesados en ser reemplazables.

Si tu estudio no puede entregar esa documentación, el código fuente en la bóveda es teatro. La documentación es lo que vuelve transferible al código.

4. Backups reales bajo tu control. La base de datos de producción tiene backups automatizados que caen en un cloud storage del que vos sos dueño y pagás, no en un backup configurado dentro de la cuenta del estudio. Lo mismo con los logs, con el almacenamiento de archivos, con cualquier cosa que tenga datos de clientes. Si la cuenta de cloud del estudio queda suspendida por falta de pago, tu negocio no se detiene.

Estos cuatro juntos, repo vivo, IP limpio, documentación de onboarding real, tus propios backups, te dan todo lo que escrow promete y más. No cuestan nada más allá del tiempo de pedirlos. Y a diferencia de escrow, te protegen el día en que el estudio deja de devolver llamadas, no tres meses después de que un agente verificó un release event.

Cuándo source code escrow sí es la elección correcta

Hay casos estrechos donde escrow tiene sentido incluso para una startup.

Estás licenciando un producto empaquetado, no comprando un build a medida. Un proveedor SaaS te vende su software, vos lo corrés en tu infraestructura, dependés de él para una operación crítica. El proveedor no te va a entregar el repo vivo porque el repo vivo es su empresa. Acá, escrow hace exactamente lo que fue diseñado para hacer. Si el proveedor desaparece, te llevás el código y seguís funcionando.

Estás en una industria regulada donde la auditoría lo exige. Algunos contratos de servicios financieros, healthtech regulada y defensa imponen escrow como condición. Si el regulador lo exige, la pregunta está cerrada.

Sos el comprador grande en una relación tipo enterprise. Firmaste un contrato de software de seis cifras con un proveedor chico especializado, el software hoy es core para tu operación, y el proveedor no te va a dar el repo vivo porque licencia el mismo producto a otros clientes. Escrow es la protección residual. Este es el caso de uso original, y la única situación en la que la founder early-stage que describí al principio del artículo debería razonablemente terminar con una cláusula de escrow.

Si nada de eso aplica, y estás pagándole a un estudio para que construya un software que debería ser tuyo desde el momento en que lo hacen ship, escrow está resolviendo el problema equivocado.

Cuánto cuesta el source code escrow

El costo depende del agente y del alcance del depósito. A 2026, las tarifas vigentes para servicios estándar de escrow en EE. UU. se ven aproximadamente así. Un acuerdo de formulario estándar con beneficiario único y depósitos trimestrales sale entre USD 1.000 y USD 3.000 por año. Un acuerdo redactado a medida con varios beneficiarios, depósitos más frecuentes o release conditions especiales puede llegar a USD 5.000 a USD 15.000 por año. Los servicios de verificación, en los que el agente confirma que el depósito efectivamente compila en un build funcional, suelen ser una tarifa adicional de USD 3.000 a USD 8.000 por evento de verificación.

Para una empresa Series B+ que licencia SaaS crítico, esos números son redondeo. Para una founder seed-stage gastando USD 150.000 en un build, no lo son. El costo más grande no es la plata. Es el tiempo gastado negociando la cláusula, el ida y vuelta entre los dos equipos de abogados sobre release conditions, y los meses de revisión contractual que se llevan el deal.

Si estás pagando por escrow en un build de software a medida, hacé la cuenta contra el inventario de cuatro pasos de arriba. El inventario es gratis. El inventario te protege mejor. El inventario no necesita un abogado que lo negocie.

FAQ

¿Qué es el source code review y escrow? Son dos cosas distintas que los vendors de escrow suelen vender juntas. Source code escrow es el arreglo de depósito-y-release descrito arriba. Source code review es un servicio en el que un tercero audita periódicamente el código depositado para verificar completitud, viabilidad de build y calidad. El review es lo que confirma que el depósito es de verdad usable. Sin el review, la bóveda puede contener un snapshot no funcional. La mayoría de los acuerdos estándar de escrow no incluyen review por default. Si vas a usar escrow, el servicio de review suele ser la parte que importa.

¿Qué debería contener siempre un acuerdo de source code escrow? Una definición clara del depósito (código fuente, scripts de build, documentación, dependencias de terceros, configuración de entorno), un cronograma de depósitos con verificación, una lista cerrada de release conditions, un proceso de release definido con tiempo máximo de respuesta del agente, la supervivencia de la licencia después del release y una cláusula de indemnización para el agente. Si falta alguna de esas, el acuerdo es decoración.

¿Qué es un escrow code? Este es un concepto totalmente distinto. Un escrow code, a veces llamado escrow recovery code, es una clave de respaldo usada en sistemas de identidad para destrabar una cuenta cuando otros métodos de recuperación fallan. No tiene nada que ver con source code escrow. Los términos viajan juntos en búsqueda porque ambos contienen la palabra “escrow”, pero los sistemas no están relacionados.

¿Puedo simplemente quedarme con mi propia copia del código? Sí, y esa es la respuesta correcta para un build a medida. Si el repo vivo vive en la organización de GitHub de tu empresa y los ingenieros del estudio están agregados como collaborators, tenés algo mejor que escrow sin ningún agente y sin release condition. Los estudios que se resisten a este arreglo te están contando algo sobre cómo piensan el ownership.

¿Agregar escrow me protege si mi developer freelance renuncia? No. El escrow se dispara cuando la entidad proveedora (la empresa del freelancer) deja de operar, no cuando el individuo se va. Un freelancer puede dejar tu proyecto mañana, pasarte un tarball y nunca disparar ninguna release condition. La protección contra un único developer que se va es documentación, onboarding listo y una relación de sucesor armada antes de que la necesites, no una bóveda que no podés abrir.

La founder con la que empecé este artículo no firmó la cláusula de escrow. Le pidió al estudio el inventario de cuatro ítems y lo tuvo en dos semanas. Dieciocho meses después el estudio sigue siendo su socio, el repo está en la organización de GitHub de su empresa con historial completo, los backups caen en su cuenta de cloud cada noche, y la documentación de onboarding ya se usó dos veces para sumar ingenieros nuevos al proyecto sin que ninguno tuviera que hablar con el equipo original. Su abogado sigue incluyendo la cláusula de escrow en el template. Ella sigue tachándola. Dejaron de discutir.

El source code escrow existe para un problema real. Es el problema equivocado para la mayoría de los founders no técnicos. El problema correcto tiene una respuesta más simple.