Una entrega completa de software a medida no consiste solo en recibir una aplicación que funciona. La empresa debería poder operar el sistema, acceder a sus activos esenciales y entender qué necesita para mantenerlo o transferirlo a otro proveedor si fuera necesario.
Lo exigible en cada caso depende del contrato, el alcance, la arquitectura, las licencias y la titularidad de las cuentas. Esta checklist es una guía operativa: no sustituye la revisión contractual ni el asesoramiento jurídico cuando hay dudas sobre derechos, licencias o protección de datos.
Qué significa una entrega completa de software a medida
Conviene distinguir tres cosas que a menudo se confunden:
- Una copia utilizable: la aplicación está publicada o instalada y los usuarios pueden utilizarla.
- El código fuente y los activos técnicos: permiten revisar, compilar, desplegar y evolucionar el sistema, dentro de los límites de las licencias aplicables.
- Los derechos de explotación necesarios: determinan qué puede hacer la empresa con el software, su documentación y sus componentes.
La normativa española protege los programas de ordenador, incluidos el programa fuente, el programa objeto y la documentación preparatoria. Por eso, pagar el desarrollo no implica por sí solo adquirir todos los derechos sobre cada elemento: el contrato debe concretar si existe cesión o licencia, qué entregables cubre, para qué usos y con qué límites. El régimen aplicable puede ser distinto según la titularidad de cada componente y lo pactado entre las partes.
También hay que separar lo desarrollado específicamente para la empresa de las librerías de código abierto, componentes reutilizables del proveedor, servicios SaaS, plantillas y otros activos de terceros. Recibir el repositorio no elimina las condiciones de las licencias que afecten a esos componentes.
Qué exigir según la criticidad del sistema
No todos los proyectos necesitan el mismo nivel de entrega. Esta clasificación ayuda a priorizar, pero no es una obligación legal universal: debe ajustarse al contrato y a la arquitectura real.
Mínimo imprescindible
- Aplicación operativa en el entorno acordado.
- Manual básico de uso y relación de funcionalidades incluidas.
- Inventario de cuentas, servicios externos y responsables.
- Relación de incidencias conocidas, límites y trabajos pendientes.
- Acta o documento de aceptación con la versión entregada.
Entrega recomendable para una aplicación mantenible
- Repositorio de código fuente cuando se haya pactado su entrega.
- Documentación funcional, técnica, de instalación y de operación.
- Instrucciones reproducibles de compilación, pruebas y despliegue.
- Accesos de la empresa a infraestructura, copias, monitorización y servicios críticos.
- Inventario de dependencias, licencias y configuraciones necesarias.
Entrega ampliada para sistemas críticos o complejos
- Repositorio bajo control de la empresa desde el inicio.
- Documentación de arquitectura, integraciones, recuperación y continuidad operativa.
- Pruebas de restauración, despliegue controlado y transición a otro equipo.
- Formación o sesiones formales de transferencia de conocimiento.
- Inventario detallado de componentes y, cuando aporte valor, una SBOM.
Checklist de documentación que debería acompañar al software
La documentación debe permitir entender, desplegar y operar el sistema sin depender de explicaciones informales. El nivel de detalle ha de ser proporcional a la criticidad y complejidad del proyecto, pero normalmente incluye lo siguiente.
Documentación funcional
- Objetivo del sistema y alcance de la versión entregada.
- Módulos, flujos principales y reglas de negocio relevantes.
- Tipos de usuario, roles, permisos y configuraciones principales.
- Manual de uso para las personas que operan la aplicación.
- Limitaciones conocidas, incidencias abiertas y trabajos pendientes.
Documentación técnica y de operación
- Arquitectura, tecnologías empleadas y requisitos del entorno.
- Integraciones con otros sistemas y datos intercambiados.
- Estructura de datos relevante y dependencias técnicas.
- Pasos reproducibles para instalar, compilar, probar y desplegar.
- Configuración por entornos, sin incluir secretos en archivos o manuales sin protección.
- Procedimientos de monitorización, copias de seguridad, restauración y recuperación del servicio.
- Responsabilidades de soporte y una sesión de transferencia si el equipo de la empresa asumirá la operación.
Las prácticas de DevSecOps de OWASP diferencian la configuración segura, la gestión de secretos, los artefactos y el despliegue. Trasladado a una entrega, esto significa que no basta con un manual genérico: debe haber información suficiente para repetir las tareas operativas de forma controlada.
Código fuente, repositorio y elementos técnicos
Si el contrato contempla la entrega del código fuente, no debería limitarse a un archivo comprimido enviado al final del proyecto. Lo razonable es que la empresa disponga de acceso a un repositorio de código fuente controlado por cuentas de la organización o, al menos, pueda verificar y recibir el repositorio con las versiones relevantes.
Junto al código, revise que se entregan:
- Instrucciones para preparar el entorno, compilar, ejecutar pruebas y desplegar.
- Scripts de despliegue, migraciones de base de datos y artefactos necesarios para operar el sistema.
- Archivos de configuración de ejemplo, sin contraseñas, claves privadas ni tokens reales.
- Pruebas automatizadas disponibles y cómo ejecutarlas.
- Inventario de dependencias, avisos de copyright y licencias de terceros.
- Una relación de componentes externos y servicios necesarios para que la aplicación funcione.
En proyectos con varias dependencias, exposición a riesgos de seguridad o previsión de mantenimiento por terceros, puede ser útil solicitar una SBOM. CISA la define como un registro formal de los componentes y de sus relaciones en la cadena de suministro de software. Puede facilitar la revisión de vulnerabilidades, licencias y mantenimiento, pero no es una exigencia automática para cualquier pyme o desarrollo privado.
El código aislado no garantiza que otro equipo pueda mantener la aplicación. Para ello también necesita documentación, infraestructura accesible, configuraciones reproducibles, licencias identificadas, pruebas y conocimiento operativo.
Accesos y cuentas que conviene controlar desde la empresa
Siempre que la arquitectura lo permita, las cuentas críticas deberían crearse a nombre de la empresa desde el inicio. Así se reduce una dependencia innecesaria y se simplifica una futura transición, sin impedir que el proveedor tenga los permisos necesarios durante el proyecto.
Según el sistema, el inventario de accesos puede incluir:
- Repositorio de código y herramientas de gestión del proyecto.
- Cuenta de nube, servidores, contenedores, almacenamiento y bases de datos.
- Dominio, DNS y certificados.
- Cuentas de publicación de aplicaciones, cuando existan.
- Servicios externos conectados: correo transaccional, analítica, pasarelas, APIs u otros servicios contratados.
- Herramientas de copias de seguridad, monitorización y alertas.
La necesidad concreta depende de quién sea titular de cada cuenta y de la arquitectura. Una relación de cuentas, responsables, permisos y finalidad evita que elementos críticos queden sin control claro.
Evite las cuentas compartidas y las credenciales maestras distribuidas entre varias personas. Es preferible usar cuentas nominativas, permisos mínimos necesarios y un registro de cambios de acceso.
Cómo hacer una transición segura de accesos y secretos
La transferencia debe planificarse; no conviene resolverla con un correo que contenga todas las contraseñas. La gestión de secretos y la configuración segura requieren controles distintos, tanto para el acceso inicial como para el posterior.
- Elabore un inventario de cuentas, titularidad, responsables, permisos, servicios conectados y dependencias.
- Dé de alta usuarios nominativos de la empresa en las plataformas necesarias.
- Transfiera los permisos mediante mecanismos seguros, sin guardar secretos en el repositorio ni en documentación expuesta.
- Rote contraseñas, tokens, claves privadas y otros secretos después del cambio.
- Retire o reduzca los accesos del proveedor, subcontratistas y cuentas que ya no sean necesarias.
- Compruebe que las copias de seguridad, alertas y procedimientos de restauración siguen funcionando tras la transición.
Este proceso no implica que el proveedor no pueda conservar un acceso de soporte. Significa que ese acceso debe estar autorizado, limitado y revisable por la empresa.
Derechos, licencias y datos personales
Los derechos de reproducción, transformación y distribución de un programa corresponden al titular aplicable, con los límites y autorizaciones previstos por la normativa y por los acuerdos que resulten aplicables. Por tanto, el contrato debería indicar con precisión si la empresa recibe una cesión o una licencia, sobre qué entregables, para qué usos, durante cuánto tiempo y en qué ámbito.
Revise por separado el código desarrollado para la empresa, el programa compilado, la documentación, los componentes open source, los componentes privativos y los servicios SaaS. Una licencia de tercero puede imponer condiciones que no desaparecen porque el proyecto se haya pagado o porque se entregue el código.
Si el proveedor trata datos personales por cuenta de la empresa, debe revisarse el contrato de encargo de tratamiento, las medidas de seguridad, los subencargados y el destino de los datos al terminar el servicio. El artículo 28 del RGPD prevé que, al finalizar el tratamiento, el encargado suprima o devuelva los datos personales al responsable, a elección de este, y suprima las copias existentes salvo que una norma exija conservarlos. La aplicación concreta, incluidas las copias de seguridad y las transferencias internacionales, requiere revisión jurídica y de protección de datos adaptada al caso.
Cómo validar y documentar la aceptación de la entrega
Antes de firmar la aceptación, definan qué versión, funcionalidades, entornos, cuentas y documentos forman parte de la entrega. No hay una prueba única válida para todos los proyectos, pero estos controles aportan evidencias útiles:
- Instalar o desplegar la aplicación desde cero en un entorno limpio, cuando sea viable.
- Ejecutar pruebas funcionales acordadas y las pruebas automatizadas disponibles.
- Verificar el acceso efectivo al repositorio, la infraestructura, las bases de datos y los servicios externos.
- Comprobar que se puede realizar un despliegue controlado.
- Probar, cuando proceda, la restauración de una copia de seguridad.
- Revisar licencias, dependencias, incidencias conocidas y pendientes.
El acta de entrega puede recoger la versión entregada, el inventario de activos, los accesos transferidos, las incidencias conocidas, los pendientes, las dependencias y los criterios de aceptación aplicados. También conviene separar claramente tres conceptos: la corrección de defectos incluida en lo acordado, el mantenimiento contratado y las nuevas evoluciones.
Cuándo pedir una entrega ampliada
Una entrega básica puede ser suficiente para una aplicación pequeña y poco crítica. En cambio, conviene pedir repositorio propio, documentación ampliada, formación y un periodo de transición formal cuando el sistema es esencial para la operación, integra muchos servicios, trata información sensible, depende de infraestructura externa o va a ser mantenido por un equipo interno o un proveedor distinto.
La misma lógica sirve antes de contratar. Si aún está valorando si construir o comprar una solución, consulte Aplicaciones personalizadas para Pymes: Cómo digitalizar tu negocio de forma eficiente. Definir desde el inicio los entregables, responsables y criterios de aceptación ayuda a reducir incertidumbres cuando llegue el momento de recibir el proyecto.
Lista breve antes de aceptar el proyecto
- ¿La empresa puede acceder al repositorio, la infraestructura y las cuentas críticas?
- ¿Tiene instrucciones para instalar, desplegar, operar y recuperar el sistema?
- ¿Se han identificado dependencias, licencias y servicios de terceros?
- ¿Los secretos se han transferido de forma segura y se han rotado?
- ¿Se han probado los accesos, el despliegue y las copias de seguridad?
- ¿El contrato concreta los derechos sobre los entregables y el tratamiento de datos cuando aplica?
- ¿El acta distingue lo entregado, los pendientes, los defectos y el mantenimiento futuro?
Preguntas frecuentes
¿El desarrollador está obligado siempre a entregar el código fuente?
No necesariamente. La obligación depende del contrato, del alcance acordado, de la titularidad y de las licencias de los componentes utilizados. Si la empresa necesita poder mantener o transferir el sistema, conviene definir expresamente si se entregará el código fuente, el repositorio, qué versiones incluye y qué derechos de uso o explotación se reciben.
¿Pagar un software a medida me convierte automáticamente en propietario de todo el software?
No. El pago del desarrollo no implica automáticamente la transmisión de todos los derechos de propiedad intelectual. Debe revisarse qué se ha pactado sobre el código, la documentación, los componentes reutilizables, las librerías de terceros y los servicios externos. Para contratos concretos, es recomendable asesoramiento jurídico especializado.
¿Qué accesos debería tener la empresa desde el primer día?
Depende de la arquitectura, pero conviene que la empresa controle o pueda controlar el repositorio, la nube o servidores, dominios y DNS, certificados, bases de datos, copias de seguridad, monitorización y los servicios externos esenciales. Siempre que sea viable, las cuentas críticas deberían estar a nombre de la empresa y usar usuarios nominativos.
¿Es seguro recibir contraseñas y claves por correo electrónico?
No es una práctica recomendable para contraseñas maestras, tokens o claves privadas. Es preferible crear cuentas nominativas, transferir permisos mediante mecanismos seguros y rotar los secretos después de la transición. Los secretos tampoco deberían incluirse en el repositorio ni en documentación sin protección.
¿Qué diferencia hay entre código fuente, documentación y derechos de explotación?
El código fuente permite revisar y modificar el programa; la documentación explica cómo usarlo, operarlo y mantenerlo; y los derechos de explotación determinan legalmente qué puede hacer la empresa con esos materiales. Tener una copia del código no equivale por sí solo a disponer de derechos ilimitados sobre todos sus componentes.
¿Qué ocurre con los datos personales al terminar la relación con el proveedor?
Si el proveedor trata datos personales por cuenta de la empresa, deben revisarse el contrato de encargo, las medidas de seguridad, los subencargados, las copias de seguridad y el destino de los datos. El RGPD prevé la devolución o supresión de los datos al finalizar el tratamiento, según la elección del responsable, salvo obligación legal de conservación. La aplicación concreta debe revisarse con especialistas en protección de datos.
¿Hace falta pedir una SBOM en cualquier proyecto?
No de forma automática. Una SBOM, o inventario formal de componentes de software, puede ser especialmente útil en sistemas complejos, críticos o con muchas dependencias, porque facilita revisar vulnerabilidades, licencias y mantenimiento. En un proyecto sencillo, puede bastar con un inventario de dependencias bien documentado.
¿La entrega del código permite que otro proveedor mantenga automáticamente la aplicación?
No. Además del código, el nuevo proveedor necesitará acceso a la infraestructura y servicios, instrucciones de instalación y despliegue, configuraciones sin secretos, pruebas, dependencias identificadas, licencias aplicables y conocimiento operativo. Por eso conviene validar la entrega con accesos reales y procedimientos reproducibles.
¿Necesitas una aplicación adaptada a este proceso?
Estudiamos si una herramienta existente es suficiente o si una aplicación a medida puede encajar mejor.
