Qué pasa con tu sistema si tu programador se va

Es una de las llamadas que más recibimos, y siempre empieza parecido:

«Tenemos un sistema que hizo un muchacho hace tres años. Se fue del país y no contesta. Ahora dejó de funcionar y no sabemos qué hacer.»

Para ese momento el problema ya no es técnico: es que la empresa depende todos los días de algo que nadie puede tocar.

Vamos a ver cómo se llega ahí, cómo comprobar si estás en esa situación hoy, y qué hacer al respecto.

Por qué es tan frecuente

No es mala fe de nadie. Es cómo suelen empezar estos proyectos.

Una empresa pequeña necesita un sistema, no tiene presupuesto para una empresa de desarrollo y contrata a alguien por su cuenta. Funciona: la persona entiende el negocio, entrega algo que sirve y cobra bastante menos.

El problema aparece después. Esa persona consigue un trabajo estable, se va del país o simplemente pierde el interés. Y como todo estaba en su cabeza y en su computadora, se va con el sistema puesto.

No es un problema de freelancers. Pasa igual con un empleado interno que renuncia, o con una empresa que cierra. La diferencia no está en a quién contratas, sino en qué queda en tu poder cuando esa relación termina.

Las cinco cosas que deben ser tuyas

Esto es lo importante del artículo. Si tienes estas cinco, cualquier otro equipo puede continuar el trabajo. Si te falta alguna, estás atado.

1. El código fuente

El sistema que usas es el resultado; el código fuente es la receta. Sin él no se puede corregir ni un error de ortografía.

Debe estar en un repositorio a nombre de tu empresa —GitHub, GitLab o donde sea— y tú debes ser el dueño de esa cuenta, no un colaborador invitado por alguien más.

2. Los accesos al servidor y al dominio

El hosting, el dominio y el certificado deben estar contratados a nombre de la empresa y con un correo de la empresa.

Esta es la que más problemas causa en la práctica. El dominio registrado con el Gmail personal del programador es un caso clásico, y recuperarlo cuando esa persona no contesta puede tomar meses.

3. Los accesos a la base de datos

Donde están tus clientes, tus ventas y tu historial. Debes poder entrar y sacar un respaldo sin pedir permiso a nadie.

4. Los respaldos

Que existan, que sean automáticos y —sobre todo— que alguien haya probado restaurarlos alguna vez.

Un respaldo que nadie verificó no es un respaldo: es una carpeta con archivos que suponemos que sirven.

5. Documentación mínima

No hace falta un manual de doscientas páginas. Con un documento que explique cómo se instala el sistema, dónde está cada cosa y qué servicios externos usa, ya alcanza para que otro equipo se ponga al día en días en vez de semanas.

Cómo comprobarlo hoy

No hace falta saber de programación. Manda este mensaje a quien mantiene tu sistema:

«Necesito para nuestro archivo: el enlace al repositorio del código con acceso a mi nombre, los datos del hosting y del dominio, y un respaldo actualizado de la base de datos.»

La reacción te dice más que la respuesta.

Si en un par de días tienes todo, estás bien: revísalo una vez al año y sigue.

Si aparecen evasivas —«eso es muy técnico», «yo lo tengo guardado, no te preocupes», «el código no se entrega»— tienes un problema, y conviene resolverlo mientras la relación sigue siendo buena. Pedirlo cuando ya hay conflicto es mucho más difícil.

«El código no se entrega»

Vale la pena detenerse aquí, porque es una frase que se escucha seguido y casi nunca es cierta.

Si pagaste por un desarrollo a medida, lo normal es que el código sea tuyo. Puede haber excepciones legítimas: componentes con licencia de terceros, o un producto que se te vende como servicio y donde el código es del proveedor —así funcionan nuestros propios productos, por ejemplo, y ahí es correcto que sea así.

Pero eso debe estar claro antes de contratar, escrito en la propuesta. Si nadie lo mencionó y ahora te dicen que no se entrega, lo que hay no es una cláusula: es una forma de que no puedas irte.

Por eso lo incluimos entre las señales de alarma de una cotización en cuánto cuesta desarrollar un software a medida.

Lo que hace que un sistema sea continuable

Tener el código no basta si nadie puede entenderlo. Estas son las diferencias que se notan cuando otro equipo tiene que tomar el proyecto:

Que use tecnologías conocidas. Un sistema hecho en un framework popular —Laravel, por ejemplo— lo puede continuar mucha gente. Uno hecho sobre algo inventado por su autor, casi nadie.

Que esté actualizado. Un sistema abandonado cinco años no solo es difícil de continuar: probablemente ya tenga fallas de seguridad conocidas.

Que tenga historial de cambios. Un repositorio con el registro de qué se cambió y cuándo permite entender las decisiones. Un ZIP llamado sistema_final_v3.zip no.

Que la configuración esté separada del código. Contraseñas y claves fuera del código fuente, en un archivo de configuración aparte.

Que tenga pruebas automáticas. No es imprescindible en sistemas chicos, pero cuando existen, el equipo que llega puede cambiar cosas sin miedo a romper algo invisible.

Si ya estás en esa situación

Se sale, y con más frecuencia de la que uno imagina. El orden que seguimos es este:

Primero, asegurar los datos. Antes que nada, un respaldo completo de la base de datos en un lugar que controles tú. Aunque el sistema esté caído, la información es lo que no se puede reconstruir.

Segundo, recuperar los accesos. Dominio, hosting, servicios de correo. Los proveedores tienen procedimientos para acreditar la titularidad de una empresa; es trámite, pero se puede.

Tercero, evaluar qué hay. Un desarrollador con experiencia puede revisar el código y decirte en pocos días si conviene continuarlo o rehacerlo. Las dos respuestas son posibles y la decisión depende de qué encuentre.

Cuarto, decidir con calma. La urgencia empuja a rehacer todo de golpe, y casi nunca es la mejor opción. Muchas veces se estabiliza lo que hay, se recupera la operación y recién entonces se planifica el reemplazo por partes.

Cómo evitarlo desde el principio

Si vas a empezar un proyecto ahora, tres cosas en la propuesta escrita evitan todo lo anterior:

1. Que el código fuente queda en propiedad de tu empresa, dicho con esas palabras.
2. Que todos los servicios se contratan a nombre de la empresa, con correos de la empresa.
3. Qué se entrega al terminar: repositorio, accesos, respaldos y documentación.

Son tres líneas. Y son la diferencia entre contratar un servicio y quedar atrapado en uno.

Para cerrar

El riesgo no es que tu programador se vaya —eso pasa, es normal y no tiene nada de malo. El riesgo es que se lleve consigo la capacidad de mantener tu sistema.

La buena noticia es que se previene con una conversación y un párrafo en la propuesta. La mala es que casi nadie la tiene hasta que ya es tarde.

Si tienes un sistema funcionando y no estás seguro de en qué estado está, esa revisión se puede hacer: se mira el código, los accesos y los respaldos, y se te dice con claridad qué falta. En Norvic Software lo hacemos como parte de la consultoría técnica, y la primera conversación no tiene costo.

Saludos y éxitos.