Qué pasa con tu software si desaparece quien lo escribió

Pasa más a menudo de lo que se cree: el desarrollador cierra, el proveedor cambia de oficio, la persona que sabía cómo funcionaba se va. Y el sistema sobre el que gira la empresa se convierte en una caja que nadie sabe abrir.

Es un riesgo real y nadie lo mete en el presupuesto, porque es incómodo de nombrar mientras se firma. Se reduce con cuatro cosas.

1. Las llaves en vuestra mano

Dominios, alojamiento, buzones, cuentas de servicios externos, archivos: a vuestro nombre, con las credenciales en vuestro poder, desde el primer día. No «te las doy cuando terminemos»: desde el primer día.

Es lo más fácil de conseguir y lo que más diferencia marca. Si tenéis acceso a la infraestructura, otro proveedor puede tomar el relevo en días. Si no lo tenéis, puede llevar un mes solo entender dónde están las cosas — y a veces no se recuperan en absoluto.

2. Los datos exportables

Pedid ver, antes de firmar, cómo se exportan los datos en un formato legible por otro programa. No un formato propietario: un CSV, un volcado SQL, un JSON.

Si la respuesta es «no está previsto», ya sabéis que la relación va en un solo sentido.

3. Un documento que explique cómo está hecho

No hace falta un manual de cien páginas. Hacen falta cinco cosas escritas: dónde se ejecuta, qué servicios externos usa, cómo se accede en caso de emergencia, cómo está organizado el código, qué hay que actualizar periódicamente.

Quien escribe software bien hecho ya tiene ese documento, porque le sirve a él el primero. Pedirlo es una forma indirecta de entender cómo trabaja.

4. Código que se pueda leer

Esta no la podéis comprobar vosotros, y es la única de las cuatro que exige confianza. Pero podéis hacer una pregunta que dice mucho: «si dentro de tres años otro desarrollador tiene que meterle mano, ¿cuánto tarda en entenderlo?»

Quien responde «está todo documentado en el código» está respondiendo bien. Quien responde «total, estamos nosotros» está respondiendo a la pregunta equivocada, y quizá ese sea justo el punto.

La distinción sobre la propiedad

Hay que aclararla antes, porque genera equívocos: los datos y la infraestructura son vuestros, siempre. La propiedad del código fuente es otra cosa, y a menudo sigue siendo de quien lo ha escrito salvo compra íntegra — lo que se os da es el derecho de uso.

No es ni justo ni injusto en sí: es una condición contractual, y como tal hay que escribirla antes de empezar en vez de descubrirla después. Un proveedor que os la explica sin que se lo pidáis es buena señal.