Escrow de código fuente en un contrato de desarrollo

Entre abril y junio de 2026 entraron en concurso 1.601 personas jurídicas en España, un 11,6% más que un año antes, según la estadística que elabora el Colegio de Registradores. El total de concursos bajó respecto al trimestre anterior, pero el de empresas subió. Con ese telón de fondo se entiende que alguien te proponga un escrow de código fuente en el contrato de desarrollo de tu app. Y se entiende la incomodidad de este artículo: en un desarrollo a medida, ese depósito suele ser la respuesta equivocada a una pregunta bien planteada.

En Docastix los derechos de explotación se ceden al cliente desde el primer commit, sin lock-in ni cuota por seguir usando lo que ha pagado —el software de terceros conserva, como siempre, su propia licencia—, y es la misma política que detallamos en cuánto cuesta desarrollar un SaaS. Cuando presupuestamos desarrollo de apps móviles, nadie custodia nada en nombre de nadie: el repositorio nace en la organización del cliente si así lo pide, y si arranca en la nuestra se traspasa entero, con el historial de commits incluido. Eso no convierte al escrow en mala herramienta, sino en una herramienta para otro problema.

Respuesta rápida: ¿necesitas un escrow de código fuente en tu contrato de desarrollo?

Depende de una sola cosa: si el código es tuyo o lo tienes bajo licencia. Si es tuyo desde el primer commit, el escrow sobra, porque ya tienes lo que el depósito custodiaría. Si dependes de software que no es tuyo —licenciado, instalado en tus servidores o un SaaS crítico—, es de las pocas cosas que te protegen de verdad. Cuando te ofrecen un depósito en un proyecto a medida, la pregunta correcta no es qué cubre: es si además te ceden el código, y si no, por qué.

Si necesitas quedarte con tres ideas: el escrow protege licencias, no propiedad, un depósito sin verificar es un ZIP que nadie ha compilado y casi todo lo que buscas en él lo consigues gratis pactando propiedad y salida al principio.

Qué es un escrow de código, en tres frases

Es un contrato a tres bandas. El depositante —quien desarrolla o licencia el software— entrega una copia del material a un agente de depósito, un tercero independiente que lo custodia y no puede usarlo; el beneficiario —tú— lo recibe solo si ocurre un supuesto de liberación pactado. Lo depositado no es «el código» a secas, sino el material que permite reconstruir el producto, y lo que se libera no es la propiedad, sino un derecho de uso limitado.

En España es un contrato atípico: sin regulación propia, funciona como una figura compleja que la jurisprudencia integra con el mandato y el arrendamiento de servicios —más cerca del mandato que del depósito, pese al nombre—, tal y como resume Confilegal a partir de la sentencia del Supremo de 24 de octubre de 2014. Traducido: no hay una ley que rellene los huecos a tu favor, y lo que no escribas se integra con las reglas generales de los contratos, que es mucho menos previsible que una cláusula clara.

Escrow de código fuente en un contrato de desarrollo: la pregunta que lo ordena todo

Antes de discutir cláusulas, contesta a esto: ¿el código es tuyo o tienes una licencia de uso?

Si es tuyo, el escrow es redundante: nadie tiene que custodiar algo de lo que ya eres titular y que ya está en tu repositorio. Lo que necesitas es que esa propiedad sea real y no una frase amable en la propuesta: cesión en exclusiva a tu nombre, repositorio en una organización de tu empresa con el equipo invitado como colaborador y no al revés, cuentas de tienda e infraestructura a tu nombre y un despliegue que alguien ajeno haya ejecutado al menos una vez. Está desarrollado en la sección de contrato de cómo elegir el mejor equipo para desarrollar tu app, que es el artículo que ordena esta decisión.

Si tienes una licencia, la conversación cambia entera. No puedes exigir el código porque no es tuyo. Ahí el escrow deja de ser un parche y pasa a ser lo único que te protege de que ese producto desaparezca contigo dentro.

El error de mercado es tratar ambos casos igual. En un desarrollo a medida, un escrow sobre la mesa merece una pregunta, no un reproche: puede venir de la aseguradora del proveedor, del comité de riesgos de tu grupo o de un inversor. Pero si aparece en lugar de la cesión de derechos, estás comprando custodia donde deberías estar comprando propiedad. Y como suena serio, se cuela: parece más garantía que la cesión de derechos, cuando es menos.

Cuándo el escrow sí compensa

Cuatro escenarios en los que el depósito es la herramienta correcta.

• Software licenciado u on-premise del que dependen tus operaciones. Un ERP sectorial, un motor de cálculo, un sistema de almacén. No es tuyo y si el fabricante cierra te quedas con un binario que aguanta hasta el primer cambio de sistema operativo.
• Un SaaS crítico de un proveedor pequeño. El código solo no sirve: necesitas continuidad operativa, y eso significa depositar credenciales de infraestructura, plantillas de despliegue y una vía de recuperación de tus datos. Los agentes lo venden como producto aparte porque el problema es distinto.
• Un producto que forma parte de tu oferta a terceros. Si revendes o integras software ajeno, tus clientes te pedirán continuidad a ti, y un escrow multibeneficiario traslada esa garantía aguas abajo.
• Requisito de un cliente grande, un regulador o un inversor. DORA fija un un mínimo contractual para los servicios TIC y nuevas exigencias de terminación y salida en entidades financieras, y hay agentes españoles que orientan el depósito a ese cumplimiento, alineándolo con DORA, NIS2 y el Esquema Nacional de Seguridad. Si tu comprador lo exige, discutir si es la mejor herramienta es perder el tiempo.

Es el matiz que dejamos apuntado en precio cerrado vs bolsa de horas: en las condiciones de salida, el escrow entra cuando el código crítico no vive en tu infraestructura. Fuera de esos casos, resuelve por contrato un problema que la propiedad del código ya resuelve de raíz.

Los supuestos de liberación, y por qué casi siempre están mal redactados

Un escrow vale lo que valen sus supuestos de liberación: concurso, cese de actividad, incumplimiento sostenido del soporte y cambio de control. El fallo típico no es que falte alguno, es que están escritos de forma que nunca se activan o que acaban en pleito.

Hay además una trampa del derecho español. El artículo 156 del texto refundido de la Ley Concursal dice que «se tendrán por no puestas las cláusulas que establezcan la facultad de la otra parte de suspender o de modificar las obligaciones o los efectos del contrato, así como la facultad de resolución o la de extinción del contrato por la declaración de concurso […]». Si tu única protección es una cláusula que resuelve el contrato en cuanto se declara el concurso, no vale nada. Por eso la práctica habitual es articular el escrow como contrato autónomo con un tercero que asume la obligación de entrega, en vez de como una cláusula dentro del contrato principal. Mejora mucho tu posición, pero no la blinda: la administración concursal puede discutir si ese diseño encubre la cláusula que el 156 tiene por no puesta, y el derecho de uso que se libera sigue naciendo del depositante. Es fontanería jurídica, y por eso importa quién te la redacta.

Escode, la marca de escrow de NCC Group —parte interesada, porque vende el producto—, insiste en que los supuestos tienen que estar definidos de forma objetiva y en evitar umbrales subjetivos que generen ambigüedad en una disputa posterior. Tres ejemplos:

• «Si el depositante deja de prestar el servicio» frente a «si incumple los tiempos de respuesta del anexo de soporte en tres incidencias críticas dentro de 60 días naturales, notificadas por escrito y no subsanadas en 15».
• «En caso de quiebra» frente a «declaración de concurso, apertura de la liquidación, cese efectivo de actividad o baja registral, acreditado con documentación pública».
• «Cambio de control relevante» frente a «adquisición directa o indirecta de más del 50% del capital o de los votos, o venta de los activos sobre los que recae el software».

Añade tres cosas: plazo máximo del agente para entregar, qué pasa mientras se discute —entrega bajo custodia con procedimiento de objeción, no bloqueo indefinido— y qué derechos tienes sobre el material liberado: lo habitual es uso interno y mantenimiento, y la comercialización rara vez se concede salvo en escrows multibeneficiario. Es negociable, así que negóciala antes de firmar y no cuando la necesites.

El depósito que nadie ha compilado: el fallo más caro

Aquí se cae la mayoría de los escrows. Nadie comprueba que el depósito sirva hasta el día en que hace falta, y para entonces ya es tarde: faltará una librería interna, la clave de firma o la versión del SDK con la que compilar.

Los agentes serios ofrecen verificación por grados. Escrow London, por ejemplo, la vende como servicios con nombre propio: prueba de integridad de ficheros —que el material exista, se descifre y se descomprima—, incluida sin coste; verificación de compilación, que documenta entorno y dependencias y comprueba que el producto funciona con datos de test; verificación de despliegue en nube (AWS, Azure o GCP), con una variante que añade auditoría de calidad del código; verificación de release para SaaS, que simula una liberación sobre una instancia limpia con los scripts de infraestructura; y verificación de app móvil, que compila y ejecuta la aplicación en Android e iOS, sin incluir su publicación en las tiendas. No son peldaños de una misma escalera: los últimos son especializaciones para productos distintos y se contratan por separado.

La distinción que importa es entre «existe», «compila» y «se despliega y funciona en un entorno limpio». Solo el tercero sirve, porque el escenario real es ese: máquina nueva, equipo que no escribió una línea y nadie a quien preguntar. Qué debería contener el depósito:

• Código fuente completo, con módulos internos y scripts de build.
• Dependencias con versiones fijadas y copia de los artefactos: un paquete puede desaparecer del registro público.
• Esquema y migraciones de base de datos, con datos de ejemplo para arrancar.
• Variables de configuración documentadas: qué hace cada una y cuáles son secretos.
• Instrucciones de despliegue reproducibles, del repositorio vacío a entorno funcionando, con infraestructura como código.
• Certificados y claves de firma, o el procedimiento para regenerarlos: sin firma no publicas una actualización aunque tengas todo el código.
• Contactos técnicos y mapa de servicios de terceros: pasarela de pago, push, analítica, correo.
• Documentación de seguridad: secretos, roles y permisos, como detallamos en cómo manejar la seguridad en el desarrollo de aplicaciones móviles.

Y una regla de frecuencia: un depósito anual sobre un producto que despliega cada dos semanas está caducado el día que lo necesitas. O es automático contra el repositorio, o pacta una cadencia parecida a tu ritmo.

Qué cuesta un escrow de código fuente

Hay precios públicos, aunque no todos los agentes los publiquen. Cambian, así que la fecha del dato importa tanto como el dato: esto es lo que publicaban sus propias páginas en septiembre de 2026, en la moneda en que cada uno lo anuncia, y casi todos son precios «desde» y no tarifas cerradas.

• Escrow London anuncia su servicio base desde 1.950 € al año y la continuidad de acceso a SaaS desde 3.445 €, que incluye verificación trimestral de las credenciales de acceso. Sus servicios de verificación arrancan en 12.695 €, coste que, según su propia página, suele asumir el beneficiario. Son las cifras de su comparativa publicada en julio de 2024.
• Codekeeper publica 139 € al mes con facturación anual para un acuerdo y 259 € al mes para cinco, con 199 € de alta y la verificación por encima del nivel básico aparte.
• EscrowTech (Estados Unidos) publica 995 $ de alta y 1.595 $ al año para un beneficiario único. Si necesitas varios, su plan multibeneficiario baja la cuota anual a 1.390 $ y cobra 295 $ al año por cada beneficiario. Cada liberación cuesta 250 $.

El patrón es claro: el depósito básico ronda los 1.400-2.100 € al año más un alta, y la verificación seria cuesta más que el depósito, a veces varias veces más. Lo que mueve el precio es el número de depósitos al año, el nivel de verificación, el número de beneficiarios y el volumen custodiado.

Compáralo con lo que ese dinero compra en otro sitio. En un proyecto medio de los que presupuestamos, en torno a 40.000 €, el mantenimiento anual va del 15% al 20% según desglosamos en cuánto cuesta mantener una app: entre 6.000 y 8.000 € al año. Un escrow con verificación seria se acerca a esa cifra o la supera. Si el presupuesto no da para las dos cosas, ordénalas por probabilidad: el escrow te cubre de que el proveedor desaparezca, que pasa a veces; el mantenimiento, de que el producto se degrade solo, que pasa siempre.

Lo que protege más que un escrow en un desarrollo a medida

En orden de importancia. Casi todo sale gratis si se pacta al principio, y lo que no, cuesta menos que un escrow.

1. Cesión de derechos en exclusiva por escrito. De todos los derechos de explotación del software y los diseños, a tu nombre, sin límite temporal ni territorial. Sin esto, lo demás es decoración.
2. Repositorio a tu nombre, con el traspaso pactado por escrito. Lo ideal es que nazca en una organización tuya con el equipo invitado como colaborador. Si arranca en la del proveedor, que el contrato diga cuándo se transfiere y que se transfiere entero. Eso es lo que ningún escrow te da: historial, ramas y el contexto de por qué las cosas están como están. Un ZIP no lo tiene.
3. Cuentas de tienda e infraestructura a tu nombre. Apple a 99 € al año y Google Play con su pago único de 25 dólares, más nube, dominio, pasarela y correo, con el detalle en cuánto cuesta hacer una app. Si son del proveedor, tu app vive de prestado aunque el código sea tuyo.
4. Despliegue documentado y reproducible, ejecutado al menos una vez por alguien que no lo escribió. Un README que nadie ha seguido es una hipótesis: la prueba es que una persona ajena al código levante el entorno desde cero con el documento delante. Es trabajo real, así que pídelo como entregable y no lo des por incluido —nosotros lo preparamos como runbook cuando el proyecto lo pide—, con la misma disciplina del proceso de desarrollo de aplicaciones móviles.
5. Cláusula de salida con traspaso definido. Preaviso por ambas partes, código documentado, credenciales, instrucciones de despliegue y horas de acompañamiento al equipo entrante. Elige antes la fórmula económica: la comparamos en precio cerrado vs bolsa de horas.

Ese conjunto cubre más escenarios que un depósito, incluidos los que el escrow ignora: que el proveedor siga vivo pero deje de interesarle tu proyecto. El escrow se activa cuando alguien se muere; la propiedad funciona todos los días.

Checklist: qué exigir según el tipo de contrato

Desarrollo a medida. Cesión en exclusiva, repositorio en tu organización desde el primer commit, cuentas e infraestructura a tu nombre, lista de librerías de terceros con su licencia, despliegue reproducible y cláusula de salida. Escrow: no. Si te lo ofrecen como sustituto de lo anterior, pregunta por qué.

Licencia on-premise crítica. Agente identificado en el contrato, supuestos objetivos y medibles, verificación que llegue al despliegue en un entorno limpio y no se quede en que el código compila, derecho de uso y mantenimiento por escrito, plazo máximo de entrega y quién paga qué.

SaaS de un proveedor pequeño. Escrow de continuidad, export periódico de tus datos en formato abierto, credenciales depositadas, prueba de recuperación anual y un plan escrito de las primeras 72 horas. La continuidad de un SaaS es infraestructura, no código. Cuando el SaaS es tuyo, esto se diseña desde dentro y forma parte de cómo montamos plataformas SaaS.

Te lo exige un cliente o un inversor. Pide su política por escrito, negocia el nivel de verificación —la partida cara— y aclara quién paga. Aprovéchalo: un depósito verificado te obliga a tener el despliegue reproducible, y eso sirve aunque nadie lo libere.

Conclusión

El escrow de código no es humo. Es una herramienta para un problema concreto: depender de software que no es tuyo. Ahí, bien redactado y bien verificado, es de las pocas cosas que te salvan. Fuera de ahí, compra tranquilidad en vez de control, y lo peor es que sirva de excusa para no discutir lo importante: de quién es el código.

Si vas a firmar un desarrollo a medida y en el borrador aparece un escrow, no lo taches: úsalo como pregunta. Por qué hace falta custodiar algo que debería ser tuyo, dónde vivirá el repositorio, a nombre de quién estarán las cuentas y quién ha ejecutado el despliegue desde cero. Si las respuestas son buenas, el depósito sobra solo; si son vagas, ya sabes qué contrato tienes delante.

Nada de esto es asesoramiento jurídico: no lo damos. Los ejemplos de redacción son ilustrativos y el efecto de cada cláusula depende del contrato completo y de tu caso, así que la parte legal que la vea tu abogado. Lo que sí sabemos es la parte técnica: qué tendría que contener un depósito de tu producto para que sirva el día malo, y si tu proyecto necesita uno. Si prefieres empezar por el dinero, la calculadora de presupuesto te da un rango en minutos; si quieres contarnos el caso, estamos en contacto.