Una aplicación puede estar entregada y seguir dependiendo de una cuenta del proveedor, de una máquina configurada solo por él o de datos que no sabes recuperar. Tener una copia del repositorio es útil, pero no resuelve por sí solo esas dependencias.
Antes de encargar software, separa derechos, código, cuentas, datos, documentación y continuidad. La pregunta no es solo «¿será mío?», sino qué recibirás, qué podrás hacer con ello y cómo comprobarías que otra persona puede hacerse cargo.
Si todavía estás preparando sistemas e integraciones para estimar el proyecto, empieza por qué reunir antes de un desarrollo de software. Aquí nos centraremos en lo que conviene acordar para recibir y continuar el trabajo.
Una palabra, seis preguntas diferentes
| Elemento | Pregunta concreta |
|---|---|
| Derechos | ¿Qué usos, modificaciones o distribución permite el acuerdo? |
| Código | ¿Qué repositorio, versión, dependencias y configuración se entregan? |
| Cuentas | ¿Quién contrata cada servicio y qué permisos tendrá tu organización? |
| Datos | ¿Qué se puede extraer, en qué formato y cómo se recupera? |
| Documentación | ¿Qué necesita alguien nuevo para arrancar y operar la aplicación? |
| Continuidad | ¿Qué comprobación permitirá saber si otro equipo puede seguir? |
Un rol de lectura puede permitir descargar el código y no dar permiso para escribir en el repositorio de entrega o administrar sus accesos. Tener un rol administrador de alojamiento puede permitir operar una instancia, pero no define por sí solo los derechos sobre el programa. Y disponer de los derechos necesarios no recupera una cuenta cuyo mecanismo de acceso nadie conoce.
Revisa cada elemento por separado. La guía para comparar propuestas ayuda a detectar cuándo una oferta dice «la aplicación será tuya» sin precisar qué se está entregando.
Concreta los derechos y los componentes de terceros
En España, la Ley de Propiedad Intelectual distingue los derechos de explotación y su transmisión. Los artículos 43 y 45 delimitan la cesión por derechos, modalidades, tiempo y territorio y prevén su formalización por escrito. En los programas de ordenador hay además reglas específicas: el supuesto del art. 97.4 sobre un trabajador asalariado no convierte automáticamente en titular a quien contrata a un proveedor externo. La LPI consolidada en el BOE permite consultar esos términos y los artículos 97–100.
Para tu proyecto, pide que el acuerdo identifique el código específico, los componentes de terceros y los usos que necesitas: operar, modificar, encargar mantenimiento a otro equipo o distribuir el producto, según el caso. La revisión jurídica del texto concreto debe resolver esas condiciones; una frase genérica sobre «propiedad total» no distingue las licencias ni los objetos que intervienen.
Pide una versión que se pueda arrancar
Un repositorio puede contener el código y necesitar además una versión de base de datos, un paquete privado, variables de configuración o un servicio externo. Ninguna de esas dependencias es necesariamente un problema. Lo que importa es que estén identificadas y que el equipo que recibe tenga una forma autorizada de resolverlas.
La entrega debería permitir responder:
- qué versión representa el trabajo acordado;
- qué requisitos técnicos y dependencias necesita;
- cómo se prepara cada entorno, sin copiar secretos en un manual;
- qué servicios externos intervienen y bajo qué cuenta;
- cómo se cargan datos de prueba, se exportan datos y se recupera una copia;
- cómo se despliega y se vuelve a la versión anterior;
- qué tareas periódicas y limitaciones quedan conocidas.
No necesitas un manual interminable. Necesitas que una persona competente, que no participó en la construcción, pueda seguirlo y señalar lo que falta. La guía de NASA sobre acceso a productos de software trata el acceso a artefactos y su seguimiento en proyectos de otra escala; aquí interesa la posibilidad práctica de revisar y continuar una versión identificada.
El archivo que solo existe en un ordenador
Imagina que las instrucciones dicen «instalar y arrancar», pero la instalación intenta buscar un paquete en la carpeta personal de quien desarrolló. El código puede estar completo y ese paso seguir dependiendo de su máquina.
La comprobación útil es preparar un entorno distinto, a partir de la entrega y sus requisitos documentados. Si la dependencia es legítima, se facilita su origen y el acceso necesario. Si se incluyó por error, se corrige y se vuelve a comprobar la instalación. Cambiar el texto del manual sin conseguir arrancar no resuelve el fallo.
Lleva las preguntas a un inventario
El inventario de entrega y continuidad deja una fila por activo, con ubicación, responsable, comprobación y estado. No guarda contraseñas, claves API ni tokens; indica el mecanismo autorizado donde se custodian cuando haga falta.
Este extracto usa Cuaderno de equipo, una aplicación interna ficticia. Son comprobaciones propuestas, no pruebas ya ejecutadas:
| Activo | Ubicación descrita | Qué se recibe | Cómo se comprueba | Estado |
|---|---|---|---|---|
| Código de la versión | Repositorio designado por la organización | Acceso y referencia de versión | Obtener esa referencia en un entorno limpio | Por comprobar |
| Dependencias y arranque | Instrucciones del repositorio | Requisitos, instalación y configuración sin secretos | Seguir los pasos desde una cuenta autorizada distinta | Por comprobar |
| Datos | Servicio de datos identificado | Esquema y procedimiento de exportación | Comparar campos y relaciones de un conjunto conocido | Por comprobar |
| Copias | Servicio de copias identificado | Frecuencia, retención y restauración | Recuperar una copia en un entorno aislado | Por comprobar |
| Alojamiento | Cuenta de organización o transferencia pendiente | Rol suficiente y configuración de despliegue | Revisar acceso, renovación y recuperación de cuenta | Pendiente |
| Operación | Carpeta documental acordada | Procedimientos y tareas periódicas | Localizar y seguir un procedimiento relevante | Por comprobar |
«Entregado» describe una transferencia. «Comprobado» necesita una evidencia. Si nadie ha ejecutado la restauración, sigue por comprobar aunque exista un archivo llamado copia de seguridad.
Ensaya el cambio de manos
Prepara un entorno controlado y un recorrido limitado. No empieces retirando accesos del proveedor para ver qué deja de funcionar.
- Identifica versión, instrucciones, servicios y datos de prueba.
- Da a quien revisa los permisos acordados, sin reutilizar credenciales personales de quien entrega.
- Arranca la aplicación siguiendo la documentación.
- Completa una tarea conocida: entrar con un rol, consultar o crear una decisión de prueba y exportarla.
- Recupera una copia en otro entorno y comprueba un dato conocido.
- Registra lo que funcionó, lo que falta y quién resuelve cada dependencia.
El objetivo es saber qué necesita la continuidad y si está bajo control suficiente. Puede requerir una licencia, un servicio externo o conocimiento especializado. Esas condiciones se pueden acordar; una dependencia desconocida no se puede planificar bien.
Si estás aceptando una versión construida, combina este ensayo con la revisión de pruebas y aceptación de software a medida. Continuidad y cumplimiento funcional son comprobaciones relacionadas, pero distintas.
Ordena los accesos antes de reducirlos
Primero identifica cuentas, identidades de servicio, roles y entornos. Confirma que la organización tiene la titularidad o el rol necesario para el trabajo previsto, que puede recuperar el acceso y que los procedimientos funcionan. Después decide qué acceso del proveedor debe mantenerse, reducirse o retirarse.
Ser administrador de una instancia puede bastar para operar y no bastar para renovar el contrato o recuperar la cuenta titular. Si un servicio no permite transferir la titularidad, registra qué información se puede sacar, qué configuración habría que reproducir y qué pasos necesita una sustitución.
Si deben cambiarse claves o accesos de una aplicación, incluye la actualización de sus dependencias y una comprobación posterior. Anotar «revocado» no demuestra que el servicio siga funcionando con la nueva configuración.
Incluye el coste de continuar y de salir
La propuesta debe separar servicios recurrentes, licencias, mantenimiento, tareas de tu equipo y trabajo de transferencia. No todo tiene que quedar contratado desde el principio, pero sí conviene saber qué está incluido, qué es opcional y qué sigue sin estimar.
Puedes formularlo así:
Necesito identificar qué código, datos, cuentas e instrucciones recibiremos; qué usos permite el acuerdo; y qué tendría que hacer otro equipo para arrancar y mantener la versión. Indica las dependencias de terceros, los costes recurrentes y lo que queda fuera de la entrega.
Conserva las respuestas en el inventario y en la propuesta. Una salida prevista no obliga a cambiar de proveedor: permite continuar por decisión, con las condiciones conocidas.
La guía para encargar software a medida conecta estas preguntas con alcance, presupuesto, comparación y aceptación.