Entrega de software: qué pedir antes de cerrar un proyecto
Qué debe incluir una entrega de software para conservar control del código, accesos y operación cuando termina un proyecto.
Terminar una app no es lo mismo que recibir un producto que tu equipo pueda operar sin depender de quien lo construyó. La entrega de software suele reducirse a una demo final, un enlace y un "listo". Ahí empieza buena parte de los problemas que aparecen semanas después.
Si estás contratando el desarrollo de un portal, una app interna o un MVP, piensa en la entrega como el momento en que recuperas control. No se trata de pedir una carpeta llena de archivos que nadie va a abrir. Se trata de poder usar, entender y evolucionar lo que pagaste.
Una demo no prueba que recibiste el producto
La demo responde una pregunta limitada: ¿hoy se ve y funciona lo que acordamos? Es útil, pero no basta. El día que una contraseña deja de funcionar, un proveedor cambia su API o necesitas agregar una persona al equipo, la pregunta cambia: ¿alguien más puede operar esto?
Una buena entrega de software deja claro dónde vive el código, quién tiene acceso a producción, qué servicios externos intervienen y cómo se recupera la operación si algo falla. Si esos puntos siguen sólo en la cabeza de la agencia o del freelancer, no terminaste de recibir el proyecto.
No hace falta que seas técnico para pedir esto. Hace falta que no aceptes que la continuidad del negocio dependa de mandar un WhatsApp a una sola persona.
El acceso importa más que una carpeta comprimida
El código fuente debe estar en un repositorio de tu organización o en uno al que tengas acceso administrativo real. "Te agregamos como colaborador" puede servir durante el desarrollo, pero no es igual que controlar el espacio donde está el proyecto.
También hay que revisar cuentas y dominios. Hosting, base de datos, analítica, correo transaccional, tienda de aplicaciones y servicios de pagos deberían tener propietarios identificables. A veces una agencia los administra por eficiencia, y eso no es automáticamente malo. El problema aparece cuando no existe una lista de qué servicio usa cada cuenta, cuánto cuesta y cómo transferirla.
En una entrega de software sana, no estás adivinando si la app depende de una tarjeta personal, un correo abandonado o una cuenta que nadie puede recuperar.
Documentar lo mínimo que evita semanas de arqueología
No necesitas una enciclopedia técnica de 300 páginas. Sí necesitas un mapa útil. Qué hace el sistema, cómo se despliega, qué ambientes existen y qué datos delicados toca. Si hay integraciones con pagos, WhatsApp, un ERP o alguna API, deja anotado para qué sirven y dónde se administran sus credenciales.
También conviene tener una guía corta para las operaciones frecuentes: crear usuarios, revisar errores, hacer un respaldo, restaurarlo y contactar soporte. El objetivo no es que el equipo de negocio se vuelva desarrollador. Es que sepa distinguir entre una incidencia operativa, una configuración y un cambio que sí requiere desarrollo.
Pedir esa documentación antes del cierre cambia la conversación. Dejas de evaluar sólo pantallas y empiezas a evaluar si el producto puede sobrevivir a su primera semana sin el equipo original encima.
La transferencia de conocimiento debe ocurrir antes del último pago
La entrega de software funciona mejor si se planea desde el inicio, no como favor al final. Una sesión de transferencia grabada, una revisión de accesos y una lista de pendientes conocidos suelen ser suficientes para un proyecto pequeño. En un sistema crítico puede requerir varias sesiones y una ventana de soporte posterior.
El momento importa porque después del pago final las prioridades se mueven. No es desconfianza, es realidad. Acordar los entregables de cierre en la propuesta o contrato protege a ambos lados: la agencia sabe qué debe preparar y el cliente sabe qué significa realmente "terminado".
Ojo, recibir el código no convierte a cualquier proveedor nuevo en experto instantáneo. Todo software tiene contexto. Pero un repositorio ordenado, accesos completos y notas honestas reducen muchísimo el costo de tomar el control.
Cerrar bien también define el siguiente paso
Un cierre profesional incluye lo que quedó fuera, los riesgos conocidos y la recomendación para la siguiente etapa. Eso no es una lista de excusas. Es una fotografía honesta del producto para que no confundas una mejora pendiente con un bug oculto.
En DevAces preferimos tratar la entrega como parte del producto, no como trámite administrativo. Si estás por contratar o cerrar un desarrollo y quieres revisar que los accesos, el alcance y la operación queden bien amarrados, platiquémoslo antes de que el proyecto se vuelva una búsqueda de contraseñas.