Cuando tu único desarrollador se va, la llamada llega un martes por la tarde. Tono amable, frase corta: «Quería avisarte con tiempo, me voy a otra empresa». Y en ese momento el gerente de una pyme de veinte empleados descubre que el negocio entero depende de una cabeza que acaba de poner fecha de caducidad.

Nosotros hemos entrado en esa escena más de treinta veces en los últimos seis años, casi siempre tarde. Y el patrón se repite con una precisión incómoda: el empresario cree que el problema es encontrar un sustituto, cuando el problema real es que no tiene ni la propiedad ni el conocimiento de su propio sistema. Contratar viene después. Mucho después.

Lo que sigue es el cronograma que usamos en esas cuatro semanas. No es teoría de manual: es el orden exacto en el que hay que atacar las cosas cuando el reloj ya está corriendo.

La llamada que paraliza a una pyme: qué pasa en las primeras 48 horas

En las primeras cuarenta y ocho horas hay que hacer tres cosas: pedir por escrito el listado de todos los accesos, transferir el dominio y el repositorio a cuentas de empresa, y fijar con la persona que se marcha un calendario de sesiones de entrega. Buscar sustituto puede esperar.

Ese intervalo decide más que las tres semanas siguientes. Y casi nunca se aprovecha.

¿Qué hace la mayoría de gerentes en esas dos jornadas? Llamar a tres agencias, pedir presupuestos de «mantenimiento» y publicar una oferta de empleo. Movimiento puro. Cero avance real, porque ninguna de esas tres acciones recupera un solo acceso ni documenta una sola línea de proceso.

Existe un criterio práctico que en el sector se conoce como el test de los 30 días: preguntarte si tu empresa podría operar y evolucionar el sistema si esa persona desapareciera durante un mes. Si la respuesta honesta es que no, el mes de preaviso no es un trámite de recursos humanos: es tu ventana de rescate.

Lo que se pierde el primer día si no haces nada

En uno de los casos que más nos marcó, una distribuidora de material sanitario de Zaragoza tardó once días en pedir los accesos. En ese plazo el chico cerró su cuenta personal de Google, y con ella desaparecieron el registro del dominio, la propiedad de Analytics y el acceso al panel del servidor. Reconstruirlo costó 4.200 euros y siete semanas de burocracia con el registrador.

La cuenta personal es la bomba de relojería. Mientras la persona sigue en nómina, la pide y te la dan en veinte minutos. Dos semanas después de su último día, lo mismo se convierte en un favor que puede concederte o no.

Por qué el pánico lleva a pedir lo que no sirve

Mira, lo que pasa es que el miedo te empuja a pedir «la documentación». Suena responsable. Y el programador, que también quiere portarse bien, te entrega un PDF de catorce páginas con el stack tecnológico, un diagrama de arquitectura bonito y una lista de dependencias.

Ese documento no te salva de nada (muy bonito para el comité de dirección, inútil a las nueve de la noche de un sábado). Cuando el sistema se caiga, no necesitarás saber qué versión de framework usa: necesitarás saber a qué proveedor llamar, con qué credenciales entrar y qué comando exacto devuelve el servicio a la vida. Son cosas distintas, y solo una de las dos vale dinero.

Por qué una sola persona acabó sosteniendo todo el sistema

Nadie decide un lunes convertir a un empleado en punto único de fallo. Se llega ahí por acumulación de decisiones razonables tomadas en momentos de prisa.

Primero fue la web. Luego el pequeño panel interno para los pedidos. Después la integración con el ERP, el script que genera las facturas, el bot que avisa al almacén. Cinco años de «ya que estás, móntame esto» y de repente el único desarrollador de la casa es el único mapa existente del negocio digital.

Los riesgos de esa concentración son siempre los mismos ocho: no tener el código fuente, tener cuentas registradas a nombre de la persona, no saber cómo se publica un cambio, no entender qué infraestructura se paga, tener copias de seguridad que nadie ha verificado, no tener nada escrito, depender de su disponibilidad para cualquier incidencia y quedar bloqueado a la hora de negociar con terceros.

Accesos a nombre personal: el origen silencioso del problema

Hicimos el ejercicio en catorce empresas de entre diez y cincuenta empleados: inventariar cuántos servicios críticos estaban registrados con un correo que no pertenecía a la compañía. La media salió en nueve. El máximo, veintitrés.

Dominios en cuentas de Gmail particulares. Repositorios de código en perfiles personales de GitHub, que no es lo mismo que un repositorio de empresa: la titularidad de la cuenta decide quién se queda con el histórico completo del proyecto. Suscripciones al hosting pagadas con la tarjeta del técnico y luego reembolsadas por caja. Certificados SSL renovados desde un panel al que solo él entra. Cada uno de esos elementos funciona perfectamente hasta el día en que deja de hacerlo.

Y aquí está el quid: no hay mala fe. Hay velocidad. Registrar un dominio con la cuenta que ya tienes abierta tarda dos minutos; hacerlo con una cuenta corporativa que aún no existe requiere pedir permiso, esperar y volver. Nadie espera cuando hay que publicar mañana.

Conocimiento que nunca se escribió en ningún sitio

La parte invisible es peor. En los relevos que hemos acompañado, en torno a tres cuartas partes del conocimiento crítico no existía en ningún soporte: vivía exclusivamente en la memoria de una persona.

Cosas como que el proceso nocturno de sincronización falla si hay más de 800 pedidos y hay que lanzarlo en dos tandas. O que el cliente de Bilbao tiene un descuento hardcodeado en una línea de código porque en 2021 no había tiempo de hacerlo bien. Nada de eso aparece en un diagrama de arquitectura. Todo eso te explota en la cara el segundo mes.

Días 1 a 7: recuperar la propiedad de lo que ya es tuyo

La primera semana tiene un único objetivo y no admite negociación: que todo lo que pagas esté a nombre de tu empresa. Nada más. No documentes todavía, no busques sustituto todavía, no rediseñes nada.

Creímos durante bastante tiempo que lo urgente era escribir manuales técnicos. Nos equivocamos en los dos primeros proyectos de este tipo: dedicamos la semana inicial a redactar documentos preciosos y llegamos al día veinte sin poder entrar en el panel del servidor, porque el aviso de renovación iba a un correo personal. Desde entonces el orden es inamovible: propiedad primero, conocimiento después.

El criterio para priorizar es brutal y sencillo: ordena los activos por «cuánto tarda el negocio en pararse si pierdo esto». El dominio suele estar arriba. El repositorio de código, también. La cuenta de Figma con los diseños, bastante más abajo.

Una cosa más. Abre una cuenta de correo corporativa genérica del tipo tecnologia@tuempresa.com antes de empezar a mover nada, porque vas a necesitarla como destino de todas las transferencias. Hacerlo a mitad del proceso obliga a repetir trámites.

Inventario de activos, dominios, repositorios y proveedores

Pide una reunión de noventa minutos, con pantalla compartida y grabación. No un email: una sesión en vivo donde él va abriendo paneles y tú vas anotando. El inventario que sale de ahí es diez veces mejor que cualquier formulario enviado por correo.

El listado mínimo que levantamos siempre incluye estos ocho bloques:

1. Registrador del dominio, cuenta asociada y fecha de renovación
2. Gestor de DNS, si es distinto del registrador
3. Hosting o nube: plan contratado y método de pago
4. Repositorio de código y permisos de administrador
5. Base de datos: credenciales y ubicación de los volcados
6. Pasarela de pago y panel de transacciones
7. Servicios externos con clave de API activa
8. Copias de seguridad, certificados SSL y licencias de pago

Anota en cada línea el coste mensual. Te vas a llevar dos sorpresas: servicios que pagas y nadie usa desde 2022, y servicios críticos que cuestan nueve euros al mes y sostienen el 40% de tu facturación.

Cómo pedir el traspaso sin romper la relación

Si entras con desconfianza, lo pierdes. La persona que se marcha tiene en su cabeza el activo más valioso de tu empresa en este momento, y la única moneda que funciona para extraerlo es la cordialidad combinada con una estructura clarísima.

Funciona encuadrarlo como gestión administrativa normal, no como auditoría de sospecha: «Vamos a pasar todo a cuentas de empresa, que es como debería haber estado desde el principio; necesito tu ayuda para hacerlo bien en estos días». Nadie se ofende con eso. En cambio, «necesito que me devuelvas los accesos» activa defensas inmediatas, porque suena a acusación de apropiación.

Un detalle que mejoró mucho nuestros resultados: ofrecer una compensación explícita por las horas de entrega, aunque siga en nómina. Entre 400 y 900 euros según la complejidad. Convierte una obligación difusa en un encargo concreto con entregables, y la calidad de lo que recibes cambia por completo.

Días 8 a 18: convertir su cabeza en documentación utilizable

Once días para vaciar una memoria de varios años. Suena imposible y no lo es, siempre que renuncies a escribirlo todo y te centres en lo que se usa.

Nuestro criterio: recoge solo aquello que alguien tendrá que hacer en los próximos seis meses. El resto puede reconstruirse leyendo el código cuando toque. Esa distinción reduce el volumen de trabajo a una quinta parte y multiplica la utilidad de lo que queda.

Si durante este bloque detectas que el sistema arrastra problemas estructurales más profundos (dependencias abandonadas, decisiones que nadie puede justificar, acoplamientos absurdos), conviene auditar tu arquitectura con ayuda externa antes de que el conocimiento se evapore por completo. Hacerlo con la persona todavía disponible para responder preguntas vale el triple que hacerlo en marzo.

Las seis preguntas que debe responder por escrito antes de irse

Seis. No veinte. Las hemos ido depurando quitando todo lo que luego nadie consultaba:

1. ¿Qué pasos exactos hay que ejecutar para publicar un cambio en producción?
2. ¿Qué se rompe con más frecuencia y cómo lo arreglas cuando pasa?
3. ¿Qué procesos automáticos corren solos y a qué hora?
4. ¿Qué parte del sistema está peor hecha y por qué la dejaste así?
5. ¿A quién llamarías tú si no supieras resolver algo aquí?
6. ¿Qué decisión tomada hace años sigue condicionando todo lo demás?

La cuarta y la sexta son las que importan de verdad, y las que ningún formulario estándar incluye. Un técnico honesto te dirá que el módulo de facturación es una chapuza que funciona por milagro, y eso ahorra meses de perplejidad al siguiente equipo. La sexta destapa las decisiones fundacionales: por qué todo corre en un servidor único, por qué no hay entorno de pruebas, por qué la base de datos tiene esa estructura rara.

Formato: documento compartido, respuestas en prosa, sin plantillas corporativas. Lenguaje suelto, donde cuente las cosas como las cuenta en una conversación de pasillo. Es más útil y se redacta en la mitad de tiempo.

Grabar el despliegue en vídeo: el atajo que casi nadie usa

Y aquí viene lo bueno. Pídele que grabe la pantalla mientras publica un cambio real en producción, narrando lo que hace. Veinte minutos de vídeo. Ese archivo ha resuelto más incidencias en los proyectos que acompañamos que cualquier manual.

¿Por qué funciona mejor el vídeo? Porque lo escrito omite lo evidente. Nadie teclea «entonces esperas a que la barra llegue al final, que tarda como dos minutos y parece colgado pero no lo está». En vídeo eso se ve. Y es precisamente ese tipo de detalle el que paraliza a quien llega nuevo.

Grabad tres: el despliegue completo, la restauración de una copia de seguridad y el diagnóstico de una incidencia típica. Una hora de material en total. Súbelo a un almacenamiento de empresa, no a una cuenta personal (ya sabemos todos cómo acaba eso).

Días 19 a 26: probar que el sistema sobrevive sin él

Tienes accesos y tienes documentos. Falta lo único que demuestra algo: comprobar que funcionan cuando la persona que los generó no interviene.

Esta semana es la que más empresas se saltan, y es la que distingue un relevo real de una carpeta llena de PDF tranquilizadores.

Simulacro de caída con el desarrollador en modo observador

El formato es este: un jueves por la mañana, alguien de tu equipo (el de sistemas, el de operaciones, tú mismo) intenta resolver una incidencia simulada usando únicamente los materiales recibidos y los vídeos. El saliente está en la sala, callado, con prohibición expresa de tocar el teclado. Solo puede responder si se le pregunta, y cada pregunta se anota.

Las preguntas anotadas son el oro de este ejercicio. Son los agujeros exactos de lo que has recogido, medidos empíricamente. En un simulacro con una empresa de logística de Valencia salieron diecisiete preguntas en dos horas: catorce se resolvieron añadiendo tres párrafos a un documento, y tres revelaron dependencias de proveedores que nadie había mencionado.

Repítelo al cabo de cuatro días con las correcciones aplicadas. Si en la segunda ronda bajas de cinco preguntas, vas bien. Si sigues por encima de diez, tienes un problema que no se arregla escribiendo más páginas: se arregla con nuestra dirección técnica externa u otro servicio equivalente que asuma la continuidad del sistema durante los meses de transición y responda de las incidencias.

Restaurar un backup de verdad, no solo comprobar que existe

«Sí, tenemos copias automáticas diarias». Perfecto. Restaura una. Ahora.

De los sistemas que hemos revisado en los últimos tres años, aproximadamente uno de cada tres tenía copias de seguridad que no se podían restaurar: ficheros corruptos, copias que excluían la base de datos, volcados almacenados en el mismo servidor que protegían. Todas ellas aparecían como «correctas» en el panel de control. Ninguna servía.

Restaura sobre un entorno aparte, cronometra cuánto tarda y anota el resultado. Ese número (cuatro horas, dos días, nunca) es tu tiempo real de recuperación ante un desastre. Y es probablemente el dato más importante que vas a obtener en todo el mes.

Días 27 a 30: decidir sucesor, agencia o congelación temporal

Ahora sí toca decidir. Con el inventario cerrado, los materiales probados y un tiempo de recuperación medido, la conversación con cualquier proveedor cambia de naturaleza: dejas de pedir que te rescaten y empiezas a contratar algo definido.

Hay tres caminos y ninguno es universalmente mejor. Contratar a otra persona en plantilla tiene sentido si el volumen de cambios es alto y constante, porque por debajo de unas veinte horas mensuales de trabajo real pagarás un sueldo completo por una ocupación parcial. Una agencia o un proveedor de mantenimiento encaja cuando necesitas disponibilidad pero no dedicación. Y la tercera opción, la que casi nadie se plantea, es no contratar a nadie durante un tiempo.

Esa decisión condiciona el presupuesto de los dos años siguientes, así que antes de firmar nada conviene tener claro cuándo necesitas un CTO y cuándo no, porque el error más caro de este mes no es quedarse corto: es contratar un perfil de dirección para un sistema que lo que necesita son ocho horas mensuales de mantenimiento correctivo.

Cuándo conviene mantener el sistema en pausa unas semanas

Suena a herejía y funciona más veces de lo que parece. Si el sistema está estable, si no hay cambios normativos a la vista y si el negocio no depende de nuevas funcionalidades en el próximo trimestre, congelar el desarrollo durante seis u ocho semanas es una decisión legítima.

Lo hicimos con un cliente del sector educativo en enero de 2024: en lugar de contratar con urgencia, dejamos el sistema en modo mantenimiento, con un proveedor de guardia a 350 euros mensuales para incidencias. Esas semanas de calma permitieron seleccionar al equipo siguiente sin prisa, y el coste total del trimestre fue cuatro veces menor que el de la contratación apresurada que estaban a punto de hacer. ¿Funciona siempre? No. Si tu producto es el negocio y los clientes esperan mejoras cada mes, congelar te cuesta mercado.

Qué exigir en el contrato del siguiente proveedor

Lo que aprendimos tras repetir el mismo error dos veces: las cláusulas que importan no son las de precio, son las de salida. Porque el día que este proveedor se vaya, vas a estar exactamente donde estabas el martes de la llamada, salvo que lo hayas previsto por escrito.

Cláusulas mínimas que recomendamos incluir:

• Todos los activos se registran a nombre de la empresa cliente, sin excepciones
• Acceso de administrador permanente para al menos una persona interna
• Procedimiento de despliegue actualizado como entregable de cada trimestre
• Preaviso de salida de 60 días con sesiones de entrega incluidas en el precio
• Código fuente en un repositorio propiedad del cliente desde el primer día
• Prueba de restauración de copias documentada dos veces al año

La cuarta se negocia mal y hay que insistir. Un preaviso de dos meses con sesiones incluidas es lo que convierte una futura crisis en un trámite aburrido (y un trámite aburrido, en esto, es el mayor elogio posible).

Cómo medir si el traspaso funcionó: cinco indicadores concretos

Treinta días después, estas cinco mediciones te dicen la verdad mejor que cualquier sensación:

Indicador	Cómo verificarlo	Umbral aceptable al día 30
Activos críticos a nombre de la empresa	Revisar titular de cada línea del inventario	100%, sin excepciones pendientes
Tiempo real de restauración	Restaurar una copia en entorno aparte y cronometrar	Conocido y por debajo de 8 horas
Preguntas en el segundo simulacro	Contar consultas anotadas al observador	Menos de 5
Personas internas capaces de publicar un cambio	Despliegue real ejecutado sin el saliente	Al menos 1
Proveedores y costes identificados	Cruzar inventario con extractos bancarios	Lista cerrada con importes mensuales

Si fallas en el primero, no has hecho nada todavía, por muchos documentos que tengas. Si fallas solo en el cuarto, estás en una posición razonable: se puede resolver contratando capacidad externa sin urgencia.

Preguntas frecuentes sobre la salida de un desarrollador único

¿Es riesgoso depender de un único desarrollador?

Sí, y el riesgo no es su competencia sino su exclusividad. Concentra ocho focos de fallo a la vez: código, cuentas, despliegue, infraestructura, copias, conocimiento no escrito, disponibilidad ante incidencias y capacidad de negociación. Cualquiera de ellos basta para detener la operación durante días.

¿Qué accesos debería controlar la empresa y no el programador?

Siempre siete: repositorio de código, infraestructura o hosting, dominio y DNS, base de datos, credenciales de servicios, claves de API de terceros y el almacenamiento donde vive la documentación. Todos a nombre de una cuenta corporativa genérica, nunca de un correo personal, aunque sea más cómodo.

¿Puede otro desarrollador continuar un sistema existente?

Puede, siempre que reciba tres cosas: el código, el procedimiento exacto de despliegue y los accesos a la infraestructura. Sin lo segundo, el tiempo de arranque se multiplica. En nuestra experiencia, un relevo con esos tres elementos cuesta semanas; sin ellos, meses.

¿Qué pasa si no existe documentación del proyecto?

Se reconstruye desde las facturas y el código, en ese orden. Los recibos de proveedores revelan qué servicios sostienen el sistema y quién los cobra. Después toca leer el repositorio. Es viable, pero sale entre tres y cinco veces más caro que preguntar mientras la persona sigue disponible.

¿Qué es un punto único de falla en software?

Es cualquier elemento cuya caída detiene todo el sistema sin alternativa posible. Suele pensarse en un servidor, pero en pymes el punto único de falla más habitual es una persona: la única que conoce el despliegue, posee las credenciales y entiende por qué el código está escrito así.

¿Cómo elaborar un plan de contingencia paso a paso?

En este escenario concreto, cuatro fases con fecha: días 1 a 7 recuperar la propiedad de los activos, días 8 a 18 extraer el conocimiento en documentos y vídeo, días 19 a 26 simular la ausencia y restaurar una copia, días 27 a 30 decidir sucesión y firmar cláusulas de salida.

¿Cuánto tarda el traspaso de un proyecto de software?

Con la persona colaborando y un sistema de tamaño medio, cuatro semanas bastan para quedar operativo. Si ya se marchó y hay que reconstruir desde facturas y código, cuenta entre dos y cuatro meses. La variable que más influye no es el tamaño del proyecto: es su disponibilidad.

¿Puedo obligar legalmente a que me entregue los accesos?

En España, los activos creados o pagados en el ejercicio de la relación laboral pertenecen a la empresa, y eso incluye dominios, código y credenciales. Dicho esto, la vía legal tarda meses y la cordial tarda días. Usa la segunda y reserva la primera para bloqueos reales.

¿Qué hago si ya se fue y no avisó?

Cambia el orden: primero contacta por si colabora de forma puntual, aunque sea remunerada, y en paralelo arranca el inventario forense revisando facturas y extractos bancarios. Los recibos de los proveedores son el mapa más fiable que te queda cuando no hay nadie a quien preguntar.

El cierre que nadie quiere oír

Total, que el verdadero problema no fue la marcha de nadie. Fue haber construido un negocio digital donde una sola persona concentraba la propiedad y el conocimiento, durante años, sin que eso generara ninguna alarma.

Este cronograma de cuatro semanas te saca del incendio. Pero si al día treinta y uno vuelves a depositar todo en una única cabeza, sea un empleado, una agencia o un freelance, estarás reservando la misma llamada para dentro de tres años. La diferencia entre una pyme frágil y una robusta no está en quién programa: está en cuántas personas pueden tomar el relevo mañana sin que nadie entre en pánico.