Checklist de traspaso: qué deberías tener cuando la agencia se va

Un patrón que aparece cuando una empresa nos pide hacernos cargo de un producto existente: técnicamente son dueños del código y aun así no pueden publicar. El repositorio está. La cuenta de despliegue pertenece a alguien que se fue. El dominio está registrado a nombre de una agencia. Nadie sabe qué variables de entorno necesita producción.

Rara vez es mala fe. Suele ser que nadie escribió lo que estaba en la cabeza de alguien. Pero el efecto es el mismo, y el momento de prevenirlo es antes de empezar el proyecto, no al final.

Qué significa realmente ser propietario

Ser dueño de un software son cinco cosas, y el código es solo la primera:

1. Tienes el código, con su historial.
2. Puedes compilarlo y ejecutarlo desde una máquina limpia.
3. Puedes desplegar sin pedir permiso a nadie.
4. Controlas las cuentas y dominios de los que depende.
5. Entiendes las decisiones lo suficiente para cambiarlo.

Si falta cualquiera, no tienes un producto: tienes una dependencia.

La lista

Código

• El repositorio está en tu organización, no en una cuenta personal ni en la de la agencia.
• Historial completo, no un único commit aplastado. El historial es documentación.
• Todas las ramas y etiquetas, incluida la que está en producción ahora mismo.
• Los archivos fuente de diseño (Figma o equivalente) en tu espacio de trabajo, con fuentes y licencias anotadas.

Compilar y ejecutar

• Un README que funcione en una máquina limpia. La prueba es literal: alguien que nunca ha visto el proyecto lo sigue y arranca la aplicación. Si se rompe en el paso cuatro, no está terminado.
• Versiones de dependencias fijadas, con lockfile en el repositorio.
• .env.example con todas las variables, para qué sirven y de dónde salen.
• Cómo ejecutar las pruebas y qué aspecto tiene una ejecución correcta.

Desplegar

• Puedes desplegar a producción tú mismo, y lo has hecho una vez antes del traspaso. No «podríamos si hiciera falta». Hecho.
• La configuración del pipeline está en el repositorio, no clicada en un panel que nadie puede ver.
• Sabes hacer rollback, y lo has probado.
• Las migraciones de base de datos están documentadas, incluido cómo ejecutarlas contra producción.

Cuentas y dominios

La categoría que más dolor causa, porque cada punto es pequeño y fácil de olvidar:

• Registrador del dominio a tu nombre, con la renovación en una tarjeta que no caduque con el contrato de alguien.
• DNS, con un registro de para qué sirve cada entrada.
• Hosting, nube, CDN.
• App Store y Play Console bajo tu organización, con las claves de firma y certificados. Perder la clave de firma de Android significa no poder volver a actualizar esa ficha nunca.
• Correo, proveedor de email transaccional y los registros DNS que lo autentican.
• Seguimiento de errores, analítica, pasarela de pago.
• Cada clave de API de terceros, y a qué cuenta se factura.

Para cada punto: ¿el propietario es una dirección que controla tu empresa? No el correo de trabajo de una persona. Una dirección compartida o de rol que sobreviva a que alguien se marche.

Comprensión

• Una nota de arquitectura breve: qué piezas hay y cómo fluyen las peticiones.
• Registros de decisiones para las elecciones que de otro modo desconcertarían al siguiente. Por qué esta base de datos. Por qué no aquel framework. Por qué existe ese apaño raro.
• Un runbook: qué se rompe, qué significan las alertas, qué hacer a las 2 de la madrugada.
• Problemas conocidos y atajos deliberados, escritos con honestidad.

Los registros de decisiones son el documento de mayor valor que nadie escribe. El código muestra qué se hizo. Solo una decisión escrita muestra qué se descartó y por qué, y eso es lo que impide que el siguiente equipo repita un error que ya has pagado.

Compruébalo antes de que acabe la relación

Un documento de traspaso es una afirmación. Verifícala mientras quienes lo escribieron siguen localizables.

Dos ejercicios, ambos valen la tarde:

• La prueba de la máquina limpia. Alguien que no ha trabajado en el proyecto coge un portátil nuevo, sigue el README y lo arranca en local. Cada punto donde se atasca es un defecto de documentación. Arregladlo ahí mismo.
• La prueba de despliegue. Tu equipo hace un cambio trivial, lo publica en producción, lo confirma y lo revierte. Si algún paso necesita a la agencia, el traspaso está incompleto.

Haz esto antes del pago final, no después. No es desconfianza; es el único momento en que todos siguen disponibles y motivados.

Móntalo así desde el principio

Casi todo esto es trivial el primer día y caro en el mes nueve. En el arranque:

• Crea las cuentas en tu organización e invita a la agencia, no al revés.
• Registra el dominio tú.
• Usa direcciones de rol para la propiedad de las cuentas desde el principio.
• Acordad que la documentación forma parte de «terminado», no es una tarea de cierre.

Montado así, el traspaso deja de ser un evento. Pasa a ser revocar unos accesos, porque todo era tuyo desde el principio.

Qué preguntar antes de firmar

Tres preguntas que merece la pena hacer a cualquier agencia, incluida la nuestra:

• ¿A nombre de quién estarán las cuentas? Al tuyo, desde el principio, es la única buena respuesta.
• ¿Podremos desplegar sin vosotros? ¿Y podemos comprobarlo durante el proyecto y no después?
• ¿Qué pasa si dejamos de trabajar juntos en el mes tres? Una respuesta honesta describe un proceso. Una vaga es un aviso.

Una agencia segura de su trabajo no tiene motivo para retener nada. Si las respuestas te resultan incómodas, eso es lo más útil que vas a aprender en toda la conversación comercial.