Entrega de software: qué pedir al terminar el proyecto

La entrega de un proyecto de software debería permitir que tu empresa utilice, administre y continúe el desarrollo dentro del alcance acordado. Para comprobarlo, pide código y versiones identificables, control de las cuentas necesarias, instrucciones de puesta en marcha, documentación de los datos, pruebas y responsables de mantenimiento.

Si estás comparando proveedores, acuerda estas entregas antes de empezar. Si el proyecto está terminando, usa la ficha de esta guía para registrar qué has recibido y qué falta. Es una propuesta práctica de recepción; las obligaciones concretas deben contrastarse con lo pactado para tu proyecto.

TL;DR — Qué pedir en la entrega

• Comprueba el acceso al código y su versión. Debe corresponder a la aplicación que estás recibiendo.
• Revisa las cuentas por separado. Repositorio, alojamiento, dominio y servicios externos pueden tener administradores diferentes.
• Pide instrucciones que otro equipo pueda seguir. La puesta en marcha debe poder repetirse fuera del ordenador del desarrollador.
• Incluye los datos y su recuperación. Identifica dónde están, cómo exportarlos y cómo se ha probado la restauración.
• Conserva las incidencias pendientes. Cada una necesita impacto, responsable y siguiente paso.
• Distingue entrega y mantenimiento. Define qué trabajo posterior está incluido y cómo solicitar el resto.
• Cierra con evidencias. Una ficha con pruebas y responsables ayuda a decidir si la recepción está completa.

Qué debe incluir la entrega de un desarrollo a medida

Cada entregable debe indicar dónde está, quién puede utilizarlo y cómo se verifica. La siguiente tabla es nuestra propuesta para preparar la recepción con el proveedor. Ajusta las filas a tu producto; un prototipo y una aplicación en producción tienen necesidades distintas.

La tabla permite comparar entregas, no certifica la calidad de una aplicación. Si todavía estás definiendo la inversión, incorpórala al alcance de tu presupuesto para desarrollar un MVP.

Código, cuentas y capacidad de continuar

Recibir el repositorio resuelve una parte del traspaso; comprueba también los servicios que necesita la aplicación. En GitHub, una transferencia puede conservar colaboradores, webhooks, secretos y claves de despliegue. Conviene revisar esos elementos expresamente al cambiar de responsable. Documentación de transferencias de GitHub.

Haz un inventario con una fila por servicio: para qué se utiliza, cuenta administradora, contacto de recuperación, facturación y persona responsable. Comprueba los permisos con las cuentas de quienes van a recibirlo. Una invitación pendiente no acredita acceso.

Pide que se aclare qué parte del sistema se desarrolla para tu empresa y qué parte depende de software, recursos o servicios de terceros. Poder descargar código no responde por sí solo a todas las preguntas sobre su uso posterior. Si el alcance o las licencias no están claros, deja el punto pendiente de aclaración antes de dar por cerrada la recepción.

Para las credenciales, utiliza un gestor adecuado y accesos limitados a la función de cada persona. Documenta dónde se administran y planifica la sustitución de claves técnicas y la revocación de accesos que dejen de ser necesarios, comprobando sus dependencias. La guía de gestión de secretos de OWASP explica los principios de mínimo privilegio, rotación y revocación. La ficha compartida de entrega no debe contener contraseñas.

Si tu producto combina una herramienta comercial y una integración propia, identifica sus límites por separado. La guía sobre SaaS o software a medida ayuda a distinguir esas responsabilidades.

Una prueba de continuidad antes de cerrar

Pide al equipo receptor que complete un recorrido usando los materiales entregados. Ver al proveedor manejar la aplicación permite conocerla; para comprobar la documentación hace falta que otra persona la siga.

Proponemos esta secuencia, adaptable al alcance:

1. Identificar la versión recibida y preparar un entorno de prueba con las instrucciones disponibles.
2. Configurar sus dependencias mediante accesos autorizados y datos ficticios o preparados para pruebas.
3. Completar una tarea de negocio, como crear un encargo y consultar su estado con los roles previstos.
4. Comprobar el procedimiento de recuperación acordado en un entorno aislado y registrar el resultado.
5. Anotar cualquier paso que requiera instrucciones adicionales, asignarle responsable y repetir la comprobación cuando se resuelva.

AWS incluye la prueba de procedimientos de recuperación entre sus principios de fiabilidad. Aplicado a esta entrega, nuestra recomendación es conservar el resultado de la prueba y sus límites, además de la descripción del procedimiento. Principios de fiabilidad de AWS.

Ejemplo ficticio: una empresa recibe una herramienta de pedidos. Su equipo abre el repositorio y consigue iniciar sesión en pruebas, pero el envío de avisos depende de una cuenta que sigue administrando exclusivamente el proveedor. La ficha registra esa dependencia, quién debe resolverla y cómo se comprobará. La entrega sigue pendiente en ese punto aunque las pantallas funcionen.

Ficha de recepción para copiar

Una ficha útil vincula cada comprobación con una evidencia y una decisión. Puedes copiar este modelo en el documento compartido del proyecto. Es un recurso de Apogeo para organizar la revisión, no un modelo de contrato ni una auditoría de seguridad.

Proyecto y versión recibida:
Fecha de revisión:
Responsable de la empresa:
Responsable del proveedor:
Persona que continuará el trabajo:

Por cada entregable:
- Qué estaba acordado:
- Enlace o ubicación del material, sin credenciales:
- Quién tiene acceso y quién lo ha comprobado:
- Prueba realizada y entorno utilizado:
- Evidencia del resultado:
- Estado: verificado / pendiente / no aplica, con motivo:
- Limitación o incidencia:
- Responsable y fecha acordada del siguiente paso:

Al cerrar la revisión:
- Funciones que pueden utilizarse:
- Pendientes que impiden la recepción prevista:
- Pendientes que se aceptan expresamente y sus condiciones:
- Alcance y contacto del mantenimiento:
- Próxima revisión, si procede:
- Decisión registrada por las personas responsables:

Evita marcar una fila como verificada únicamente porque existe un archivo. La evidencia debe corresponder a su finalidad: una guía de despliegue se comprueba siguiéndola; un acceso, entrando con el usuario receptor. Si la empresa no dispone de equipo técnico, puede encargar esa revisión a quien vaya a mantener el producto.

Entrega y mantenimiento: qué dejar claro

El cierre debe explicar quién se ocupa del producto a partir de ese momento. Propón separar correcciones de defectos del alcance recibido, actualizaciones de dependencias, atención a incidencias y nuevas funciones. Para cada bloque, pide tareas incluidas, exclusiones, canal de contacto y condiciones acordadas.

Pregunta también quién recibe una alerta, quién decide una intervención y cómo se solicita una mejora. No presupongas atención permanente ni un plazo de resolución por la palabra «mantenimiento». Un tiempo de respuesta y un tiempo de resolución describen compromisos diferentes.

Esta definición puede incorporarse desde el inicio a un encargo de desarrollo de producto digital. Así la recepción se prepara durante el trabajo y no depende de reconstruir decisiones al final.

Preguntas frecuentes

Estas preguntas ayudan a cerrar los puntos que suelen quedar implícitos en una entrega. Conviene responderlas con referencias a los materiales y al alcance del proyecto.

¿Basta con que me entreguen un ZIP con el código?

El ZIP debe acompañarse de lo necesario para utilizar lo acordado. Comprueba versión, dependencias, instrucciones, cuentas y datos. Un archivo puede formar parte de la entrega, pero su existencia no demuestra que otro equipo pueda iniciar, publicar o mantener la aplicación. Pide una prueba con el material recibido.

¿Tienen que estar todas las cuentas a nombre de mi empresa?

Debes acordar qué cuentas controla tu empresa y cuáles forman parte de un servicio gestionado. En cada caso, documenta permisos, facturación, recuperación y procedimiento de salida. Si una cuenta agrupa recursos de varios clientes, pide una solución para tu proyecto; no acceso a información ajena.

¿Quién comprueba la entrega si no tengo desarrolladores?

La persona o el equipo que vaya a mantener el producto puede verificar la parte técnica. Tu empresa debería comprobar también el recorrido de negocio y las tareas de administración. Pide resultados comprensibles, pendientes concretos y una explicación de los límites de la revisión, en lugar de una aprobación genérica.

¿Qué hago si quedan errores al final del proyecto?

Registra su impacto y una decisión para cada pendiente. Distingue lo que impide utilizar el alcance previsto de lo que puede tratarse después bajo condiciones acordadas. Asigna responsable y siguiente comprobación. La clasificación debe hacerse con quienes responden por el producto, no solo contando cuántas incidencias quedan.

¿La entrega incluye mantenimiento y nuevas funciones?

Comprueba qué servicios posteriores se han incluido expresamente. Pide que se diferencien corrección, actualización, atención a incidencias y ampliación funcional. Una función nueva puede requerir otro alcance. Dejar estos bloques escritos ayuda a evitar que la empresa y el proveedor esperen trabajos distintos después de la entrega.

¿Puedo utilizar esta ficha al cambiar de proveedor?

Sí, como inventario y registro de comprobaciones del traspaso. Añade las dependencias del equipo saliente, la persona receptora y los pasos de transición. Haz las pruebas en un entorno adecuado y coordina los cambios de acceso con quienes operan la aplicación para no interrumpirla durante la revisión.

Recomendación final

Acuerda la entrega antes de contratar y ciérrala con una prueba de continuidad. El inventario aclara qué vas a recibir, la prueba muestra si se puede utilizar y la ficha deja visibles los pendientes. Ajusta el nivel de revisión a la importancia del producto y al equipo que lo operará.

Si estás preparando un proyecto, pide a cada proveedor que explique cómo entregará estos materiales y quién comprobará la recepción. Esa respuesta aporta un criterio concreto para comparar propuestas.

En resumen

• La entrega debe permitir continuar el trabajo. Define quién recibirá y operará el producto.
• Código y versión deben corresponder. Identifica qué aplicación se está entregando.
• Cada cuenta necesita un responsable conocido. Comprueba acceso, recuperación y facturación.
• La documentación se verifica usándola. Pide una puesta en marcha por el equipo receptor.
• Los datos necesitan un procedimiento de recuperación comprobado. Conserva su resultado y sus límites.
• Los pendientes necesitan una decisión. Registra impacto, responsable y siguiente paso.
• El mantenimiento debe tener un alcance claro. Diferencia operación, correcciones y evolución del producto.

Fuentes consultadas

Las fuentes sostienen las recomendaciones técnicas indicadas; la tabla y la ficha son propuestas propias de Apogeo. Consultadas el 7 de noviembre de 2026.

• GitHub: transferir un repositorio.
• OWASP: gestión de secretos.
• AWS: principios de fiabilidad y pruebas de recuperación.

Siguiente paso

Describe qué producto necesitas y quién se encargará de él después del lanzamiento. En Apogeo podemos ayudarte a definir el alcance de tu producto digital. Cuéntanos tu proyecto y qué necesitaría recibir tu equipo para continuar el trabajo.