Quién debe ser propietario del código y la infraestructura

Cuando pagas por un desarrollo a medida, lo que estás comprando es el sistema. Parece evidente y no siempre queda escrito, y la diferencia aparece el día que quieres cambiar de proveedor o que el proveedor deja de responder.

Qué debe estar a nombre de tu empresa

La regla es sencilla: todo aquello sin lo cual el sistema no funciona.

• El dominio. Registrado por tu empresa, con el correo de recuperación bajo tu control. Es lo primero que se pierde y lo más difícil de recuperar.
• El repositorio de código. En una cuenta tuya, con acceso para el proveedor. No al revés.
• El servidor o el servicio en la nube. La cuenta y el medio de pago a tu nombre.
• La base de datos y sus respaldos, con capacidad de descargarlos cuando quieras.
• Los servicios de terceros: pasarela de pago, envío de correos, almacenamiento, mensajería.
• Las cuentas de las tiendas de aplicaciones, si hay aplicación móvil. Publicar bajo la cuenta del proveedor significa que la aplicación es suya.

Que el proveedor tenga acceso a todo esto es normal y necesario. Lo que no es normal es que sea el titular.

Qué dice un contrato razonable

Tres puntos, y se escriben en pocas líneas:

1. La propiedad intelectual del código desarrollado es del cliente, desde que se paga. No al terminar el proyecto: desde que se paga cada etapa.
2. El proveedor conserva derecho sobre sus componentes propios previos, y te otorga licencia para usarlos indefinidamente. Esto es legítimo: casi todos tenemos utilidades que reutilizamos entre proyectos. Lo que importa es que la licencia no caduque ni dependa de seguir contratando.
3. A la salida se entrega todo: código, documentación, accesos y una copia de la base de datos, dentro de un plazo definido.

La zona gris de las licencias

Hay proveedores que desarrollan sobre una plataforma propia y venden configuraciones de ella. Es un modelo válido y a veces conveniente: sale más rápido y más económico.

Lo que hay que saber es que en ese caso no estás comprando un sistema, estás contratando un servicio. Si la relación termina, el sistema no se va contigo. No está mal, siempre que lo sepas al firmar y el precio lo refleje.

La pregunta que lo aclara todo: si mañana contrato a otra persona, ¿puede tomar esto y seguir? La respuesta debe ser sí, y sin condiciones.

Cómo verificarlo, no solo pactarlo

Un contrato que dice lo correcto y una realidad que no lo cumple es una situación bastante común, y sin mala intención: simplemente nadie revisó.

Cada cierto tiempo conviene comprobar:

• Entrar al panel del dominio con tus credenciales.
• Entrar al repositorio y ver el código.
• Descargar un respaldo de la base de datos y abrirlo.
• Revisar a nombre de quién están las cuentas de los servicios de terceros.

Si alguna de las cuatro no se puede hacer sin pedirle nada a nadie, ahí hay algo que resolver mientras la relación es buena.

Por qué importa antes de que pase algo

Todo esto parece burocrático mientras el proyecto va bien. Se vuelve urgente el día que el proveedor cambia de rumbo, sube el precio, deja de responder o simplemente cierra.

Cuando eso ocurre, la diferencia entre tener los accesos y no tenerlos es la diferencia entre contratar a alguien que continúe y volver a empezar.

En nuestros proyectos el código, los repositorios y la infraestructura quedan desde el primer día en cuentas a nombre del cliente, con la documentación para que cualquier equipo pueda continuar. Puedes ver cómo trabajo el desarrollo de software a medida, o si ya tienes un sistema en esta situación, cómo retomar un sistema sin quién lo mantenga.