Entrega de software a medida: código, accesos y operación

La entrega técnica es el traspaso de los recursos y el conocimiento necesarios para ejecutar, modificar y recuperar el sistema dentro del alcance acordado. No es sólo la demostración de las funciones. El responsable de operaciones confirma que el proceso sirve; el equipo IT confirma que puede mantenerlo.

Si estás comparando desarrollo de software a medida, incorporá la entrega a la propuesta inicial. Definí quién administra las cuentas, quién paga los servicios externos y quién recibe la documentación. Resolverlo al final puede obligarte a coordinar transferencias que no estaban previstas.

Separá tres preguntas: qué derechos y licencias se pactan, qué acceso técnico tiene tu empresa y quién asume la operación. El contrato define la primera; una lista de accesos y una prueba de traspaso permiten comprobar las otras. Administrar un repositorio no prueba por sí solo una cesión de derechos.

Armá una fila por recurso con su ubicación, responsable de la empresa, permiso requerido, evidencia y dependencia pendiente. No guardes contraseñas en esta tabla: registrá dónde se gestionan. Esta matriz es una propuesta de revisión técnica que se adapta a tu sistema, no una certificación.

Pedí el repositorio con historial, las instrucciones de instalación, la versión del entorno y el identificador del commit o release entregado. Ese identificador debe poder relacionarse con la aplicación desplegada. Sumá las migraciones de base de datos y las pruebas relevantes; un ZIP aislado no explica qué versión estás recibiendo ni cómo reproducirla.

En GitHub, transferir un repositorio requiere permisos y tiene condiciones para la cuenta de destino. La documentación indica que colaboradores, webhooks y secretos pueden seguir asociados tras el traspaso. Por eso, recibir el repositorio y revisar quién conserva acceso son tareas distintas.

Si el código queda desde el inicio en la organización de tu empresa, verificá igualmente que las automatizaciones no dependan de cuentas personales del proveedor. Pedí un inventario de bibliotecas, servicios y licencias: tener acceso al código propio no elimina las condiciones de los componentes de terceros.

Enumerá hosting, base de datos, dominio y DNS, almacenamiento, correo y APIs externas. Para cada servicio, verificá quién administra, quién paga, dónde llegan las alertas y quién puede recuperar el acceso. Puede haber recursos compartidos del proveedor que deban separarse; dejalos identificados antes de acordar el traspaso.

Los mecanismos dependen del producto. Vercel documenta qué se transfiere con un proyecto y qué necesita tratamiento aparte; por ejemplo, los datos de monitoreo no se transfieren y Vercel Blob tiene un mecanismo separado. Copiar el repositorio no sustituye esta revisión.

En Supabase, el traspaso entre organizaciones tiene requisitos de roles e integraciones. Además, transferir la organización del proyecto no cambia su región. Revisá las condiciones vigentes del servicio y del plan antes de fijar una ventana de cambio; no supongas que todos los recursos se trasladan igual.

Elegí una persona del equipo receptor y un entorno de prueba con datos autorizados para ese uso. Debe poder partir de la versión entregada, configurar el entorno con las instrucciones y ejecutar las pruebas acordadas. El proveedor puede observar y aclarar; cada paso que dependa de una explicación oral se incorpora a la documentación.

Después, realizá un cambio pequeño y reversible, desplegalo en ese entorno y volvé a la versión anterior. Si el alcance incluye recuperación de datos, probá la restauración acordada en un entorno aislado. Registrá versión, resultado, responsable y pendientes. No uses producción para improvisar este ejercicio.

Por ejemplo, en un portal interno, el receptor podría cambiar un texto, ejecutar los tests, publicar la versión de prueba y revertirla. Si sólo el proveedor puede completar la publicación porque conserva un acceso personal, hay una dependencia pendiente. El ejemplo es ilustrativo: la prueba final debe reflejar tu arquitectura y tus restricciones.

La posibilidad de cambiar de proveedor y la necesidad de soporte son compatibles. Dejá por escrito quién vigila incidentes, actualiza dependencias, gestiona backups y paga renovaciones. Diferenciá un defecto del alcance entregado de una nueva funcionalidad y acordá cómo se solicita cada trabajo.

El acompañamiento posterior necesita alcance y condiciones propios. No des por incluido un servicio de guardia, una respuesta inmediata o una migración futura. Si opera tu equipo IT, el traspaso debe dejar claras sus responsabilidades. Si opera el proveedor, la documentación y el acceso de tu empresa siguen siendo relevantes.

Antes de retirar accesos, verificá que las integraciones y tareas programadas usan identidades adecuadas. La revisión o rotación de credenciales se planifica con el responsable técnico, para evitar interrumpir servicios que todavía las usan.

Indicá qué sistema necesitás, qué equipo lo recibirá, qué cuentas ya tiene la empresa y qué restricciones de infraestructura existen. Pedí que el alcance incluya la matriz de entrega, la documentación y la prueba de traspaso pertinentes. Si todavía no conocés las dependencias, el relevamiento y su alcance se acuerdan como trabajo pago.

Duotach desarrolla software a medida para empresas. Podés consultar por un desarrollo y describir el resultado operativo y los requisitos de entrega que necesitás. La propuesta debe precisar el trabajo contratado y las condiciones del acompañamiento; esta guía no promete una revisión gratuita de tu sistema.