Tu desarrollador desapareció: qué hacer en las primeras 48h

La llamada llega un martes. La web está en línea, la aplicación funciona, el checkout procesa pedidos — y nadie en la empresa sabe dónde se ejecuta todo eso. El desarrollador dejó de responder hace tres semanas. El dominio caduca en cuarenta días, el certificado en diez, y la única persona que alguna vez tecleó la contraseña del servidor no coge el teléfono.

Este texto no va de demandar a nadie. El pleito es asunto de tu abogado y no te devuelve el acceso al panel de DNS. Es una guía operativa de las primeras 48 horas, ordenada por cuánto riesgo elimina cada paso: qué hacer en las dos primeras horas, qué hacer el primer día y qué solo tiene sentido cuando baja la polvareda. Si solo tienes tiempo para el primer bloque, haz el primer bloque. Es el que impide que el daño siga creciendo.

Un proyecto huérfano es el software que sigue funcionando en producción después de que se fuera la única persona capaz de operarlo — sin traspaso de accesos, sin documentación y sin nadie en la empresa que pueda hacer el siguiente despliegue.

Primeras 2 horas: inventario de titularidad, no de código

El instinto es abrir el código. Es el instinto equivocado. El código parado no te hace daño; una cuenta caducada sí. La primera pregunta no es “qué hace este sistema”, sino “qué controla realmente la empresa hoy”.

Monta una hoja de cálculo con una fila por activo y tres columnas: a nombre de quién está, quién puede entrar ahora, cuándo caduca. Los activos:

• El dominio. En qué registrador y a nombre de qué persona física o jurídica. Este es el punto número uno: perder el dominio es perder el negocio, y el plazo de renovación no espera a tu reorganización interna.
• DNS. Suele estar en un proveedor distinto del registrador. Es lo que apunta el dominio al servidor.
• Hosting o cuenta de nube. Incluida la tarjeta de crédito registrada. Una factura cargada a la tarjeta personal del desarrollador es una bomba de relojería.
• Repositorio de código. GitHub, GitLab, Bitbucket — y bajo qué organización.
• Servicios de terceros. Pasarela de pago, correo transaccional, SMS, almacenamiento, CDN, monitorización, seguimiento de errores.
• Cuentas de tiendas de aplicaciones, si hay una app publicada.
• La base de datos, si vive fuera del servidor principal.

Aquí hay una distinción que despista a mucha gente: ser titular no es lo mismo que tener acceso. ICANN lo dice de forma explícita: cuando una organización externaliza la gestión de sus dominios, debe seguir figurando como titular registrante, con independencia de quién ocupe el contacto administrativo, técnico o de facturación. Si tu empresa es la titular y el desarrollador es solo el contacto administrativo, tienes un problema de trámite, resoluble con documentación. Si el titular es él, tienes un problema de negociación. Son situaciones muy distintas y conviene saber en cuál estás antes de tomar cualquier otra decisión.

Siguientes 6 horas: revocar accesos, en el orden correcto

Un exproveedor con credenciales activas no es un riesgo teórico. Es una credencial válida sin dueño responsable — justo la categoría que el Data Breach Investigations Report 2025 de Verizon señala como vector de acceso inicial en el 22% de las brechas analizadas, el vector más frecuente del informe. No hace falta suponer mala fe: basta con que le roben el portátil o con que una contraseña reutilizada suya aparezca en una filtración.

Pero revocar a ciegas es como cortar cables de colores a oscuras. Una clave de API cancelada sin aviso tumba pagos, correo transaccional e integraciones — en producción y en horario laboral. Por eso el inventario va antes. Con él en la mano, rota en este orden:

1. Acceso administrativo primero. Consola del proveedor de nube, panel del registrador, cuenta raíz. Es lo que permite destruir todo lo demás.
2. Claves SSH y deploy keys del servidor. Elimina cualquier clave pública que no pertenezca a una persona identificada.
3. El repositorio. Quita al colaborador, revoca tokens de acceso personal y desactiva deploy keys huérfanas.
4. Contraseñas de base de datos y paneles de administración de la aplicación.
5. Claves de servicios de terceros, una a una, con alguien vigilando el comportamiento en producción tras cada cambio.
6. Webhooks e integraciones que apunten a direcciones que no reconoces.

Activa la autenticación de dos factores en todo mientras estás dentro. Y busca secretos versionados: un archivo .env subido al repositorio es habitual en proyectos de proveedor pequeño, y significa que la credencial se filtra junto con el código. Esa misma higiene de credenciales encabeza nuestra lista de seguridad esencial de WordPress — el login blindado y el mínimo privilegio valen para cualquier stack, no solo para WordPress.

Primer día: averiguar si el código está completo

Solo ahora entra el código. La pregunta no es “si este código es bueno”, sino “si este código basta para operar el sistema sin él”. Cuatro comprobaciones responden casi todo:

• ¿El repositorio se corresponde con lo que está en producción? Compara el commit desplegado con el último commit del repositorio. Una divergencia significa que alguien subió cambios directamente al servidor, y esa diferencia puede contener lógica de negocio que no existe en ningún otro sitio.
• ¿Puedes levantarlo desde cero? Clónalo en una máquina limpia e intenta ejecutarlo. Si el build depende de un paso que solo existía en la cabeza de quien se fue, lo descubres ahora — y no el día que necesites corregir un fallo urgente.
• ¿Existe copia de seguridad y restaura? Una copia que nunca has restaurado es una suposición, no una garantía. Restáurala en un entorno de pruebas y confirma que el sistema arranca funcional.
• ¿Cómo se hace un despliegue? Si la respuesta es “arrastrando archivos por FTP”, ya tienes identificada la primera mejora estructural.

Conviene calibrar las expectativas sobre el coste de tocar código heredado. La investigación The Developer Coefficient, de Stripe, constató que las personas desarrolladoras dedican más de 17 horas semanales a mantenimiento, depuración y corrección de código malo. El dato es de 2018 y la muestra es global, pero el orden de magnitud es el mensaje: mantener código que nadie documentó se lleva la mayor parte del presupuesto de ingeniería, no lo que sobra de él. Planifica el próximo trimestre con eso en mente, y trata el mantenimiento como hábito permanente y no como proyecto puntual, el mismo argumento del mantenimiento continuo de WordPress.

Qué es un handover — y cómo reclamarlo a posteriori

Un handover de proyecto es la entrega formal de todo lo necesario para que otra persona asuma el software sin consultar a quien se marchó. No es un gesto de buena voluntad el último día: es un entregable, y cabe en pocas páginas.

El contenido mínimo:

• Inventario de cuentas y credenciales, con titularidad y forma de recuperación.
• Direcciones del repositorio y del entorno de producción.
• Procedimiento de despliegue, escrito paso a paso, incluido el rollback.
• Dependencias externas, con coste, ciclo de facturación y contacto de soporte.
• Decisiones de arquitectura que no son evidentes en el código, y su motivo.
• Qué suele romperse, y qué se hace cuando se rompe.

Aunque el proveedor esté ausente, merece la pena enviar esa petición por escrito, por correo, punto por punto. Pasan dos cosas: a veces contesta —desaparecer suele ser un conflicto mal resuelto, no una fuga— y siempre queda registrado que lo solicitaste. Si el asunto acaba en disputa, ese registro documenta el intento.

¿De quién es el código? La regla por defecto sorprende

Aquí la respuesta cambia mucho según la jurisdicción, y la suposición habitual del comprador suele ser errónea.

En España, el texto refundido de la Ley de Propiedad Intelectual atribuye al empresario, salvo pacto en contrario, los derechos de explotación sobre el programa de ordenador creado por un trabajador asalariado en el ejercicio de sus funciones o siguiendo sus instrucciones. Lee bien ese sustantivo: la regla habla del asalariado. No cubre al autónomo ni a la agencia externa que te facturó por el desarrollo. Con un freelance, si no hay cláusula de cesión escrita, los derechos no se transfieren solos — pagar la factura no equivale a una cesión.

Otras jurisdicciones invierten el criterio: la ley brasileña de software, por ejemplo, atribuye los derechos a quien contrató el servicio salvo estipulación en contrario. La instrucción práctica es la misma en todas partes: lee el contrato que firmaste, y si no hay cláusula de cesión, consíguela antes de gastar dinero en ese código.

Una separación más que conviene mantener clara bajo presión: ser dueño del código no te da la contraseña. El derecho de autor es una disputa que se resuelve en meses; el acceso operativo decide si la web sigue en línea la semana que viene. Trata el acceso como emergencia y la propiedad como proceso.

Contratar a quien lo asuma: qué preguntar

Con el acceso recuperado y el código mapeado, toca decidir quién lo lleva a partir de ahora. Dos reglas prácticas.

Primera: encarga un diagnóstico corto y pagado antes de cualquier contrato largo. Dos semanas de lectura del sistema, con entrega de un documento de riesgos y prioridades, cuesta poco y revela mucho — también sobre el proveedor que estás evaluando.

Segunda: desconfía de quien propone reescribirlo todo en la primera conversación. La reescritura es la respuesta cómoda para quien no quiere leer código ajeno, y tira reglas de negocio que solo existen ahí. Estabiliza primero. Decide después.

Las cláusulas que impiden que se repita

El proyecto huérfano casi nunca es un fallo técnico. Es una cláusula que nadie escribió. Para el próximo contrato:

• Todas las cuentas a nombre de la empresa, con tarjeta corporativa. El proveedor recibe acceso, no titularidad.
• Repositorio en la organización de la empresa. El proveedor entra como colaborador y sale como excolaborador, con un clic.
• Handover documentado como condición del pago final. Es la única cláusula que garantiza que se escriba.
• Cesión expresa de derechos, para no depender de la regla supletoria de la ley.
• Plazo de respuesta y procedimiento de salida, definiendo qué ocurre en los 30 días posteriores al fin del contrato.

Ninguna cuesta dinero. Cuesta acordarse de escribirlas antes de empezar — y precisamente por eso casi nadie las escribe.

Si solo tienes tiempo para una cosa hoy, haz esta: averigua a nombre de quién está el dominio y cuándo caduca. Todo lo demás tiene arreglo más lento, pero lo tiene.