Qué pedir antes de firmar un desarrollo de software

Resumen:

• El código y todos los accesos a tu nombre, por escrito y desde el día uno.
• Entregables definidos como cosas verificables, no como adjetivos.
• Garantía de 60 a 90 días, con la frontera defecto/cambio escrita.
• Un procedimiento de cambios, porque los cambios van a existir.
• Una cláusula de salida: es la que te deja negociar después.

Un cliente llegó con un sistema que funcionaba bien y un problema sin salida: el programador que lo había construido no contestaba desde hacía cinco meses, y el código estaba en una cuenta personal a la que nadie más tenía acceso. El servidor seguía corriendo, el sistema seguía operando, y no se podía cambiar ni una palabra.

Había pagado 380,000 pesos. El contrato eran dos páginas con el precio, el plazo y una lista de funcionalidades. Nada de lo que sigue.

1. La propiedad del código, escrita

Una cláusula de cesión total de derechos patrimoniales a tu favor, al pago final, sobre todo el código escrito para el proyecto. Sin reservas, sin licencias de uso: cesión.

Dos cosas que conviene distinguir. El proveedor seguramente usa componentes de código abierto y bibliotecas de terceros: eso es normal y no se cede, se licencia, y basta con que la lista esté en la entrega. Lo que sí se cede es todo lo que se escribió para ti.

Y si el proveedor tiene una base propia que reutiliza entre clientes, que lo diga y que te dé una licencia perpetua, irrevocable y transferible sobre ella. Eso es aceptable. Lo que no es aceptable es descubrirlo el día que quieras mover el proyecto.

¿De quién es el código de un software que yo pagué?

De quien lo diga el contrato. En México, si no se pactó nada, los derechos patrimoniales de una obra por encargo suelen quedar del lado de quien la encargó, pero depender de eso es mal negocio: lo que se discute después nunca es la ley, es el acceso práctico al repositorio. Pide una cláusula explícita de cesión total.

2. Los accesos, a tu nombre, desde el principio

Esta es la que de verdad protege, porque es la que funciona sin abogados.

Nota el repositorio: tu organización, proveedor invitado. No «el proveedor te da una copia al final». La diferencia es que en el primer caso el código llega a tu lado todos los días, y en el segundo depende de que alguien cumpla una promesa cuando la relación ya se rompió.

¿Qué accesos debo tener yo y no solo el proveedor?

El dominio, el servidor o la cuenta de nube, el repositorio de código, la base de datos, las cuentas de desarrollador de las tiendas y los servicios de terceros que facturen a tu nombre. Si cualquiera de esos está solo en manos del proveedor, el proyecto no es tuyo en la práctica.

3. Entregables verificables

«Panel de administración intuitivo» no es un entregable: es una opinión, y no hay manera de declararla cumplida o incumplida. «Panel donde un usuario con rol de administrador puede crear, editar y desactivar productos, y exportar el catálogo a hoja de cálculo» sí lo es.

La prueba para saber si un entregable está bien escrito: ¿podría una persona ajena al proyecto, leyendo la línea, determinar si se cumplió? Si hace falta discutirlo, está mal escrito, y se va a discutir justo cuando haya dinero en juego.

Incluye en la lista las cosas que no son pantallas: el documento de despliegue, el instructivo de operación, los datos migrados, la capacitación. Son las que se olvidan y las que hacen falta.

4. Garantía, con su frontera

Sesenta a noventa días desde producción, corrección de defectos sin costo. Y la definición, porque es lo que se pelea:

Defecto: el sistema hace algo distinto de lo que dice el entregable. Se corrige sin cobrar.

Cambio: el sistema hace lo que dice el entregable y quieres que haga otra cosa. Se cotiza.

La frontera parece obvia y no lo es, así que vale la pena un ejemplo en el contrato mismo. Dos líneas de ejemplo ahorran una discusión de dos semanas.

¿Cuánto debe durar la garantía de un desarrollo?

De 60 a 90 días después de salir a producción, cubriendo corrección de defectos sin costo. Lo que hay que definir con cuidado es qué cuenta como defecto y qué cuenta como cambio: un comportamiento distinto de lo especificado es defecto; una funcionalidad que no se pidió es cambio y se cobra.

5. Un procedimiento de cambios

Los cambios van a existir. En un proyecto de tres meses es normal que un 20 o 30 por ciento del alcance se revise, porque viendo el sistema funcionando se entiende lo que no se entendía en la junta inicial.

Lo que hace falta no es prohibirlos: es que haya un camino. Quién los pide, quién los cotiza, en cuántos días, y qué pasa con la fecha de entrega. Sin ese camino, los cambios entran por conversación de WhatsApp, nadie ajusta el plazo, y a los dos meses el proyecto va tarde sin que ninguna de las dos partes sepa por qué.

¿Conviene pagar por hora o por precio cerrado?

Precio cerrado para alcances bien definidos, que es lo normal en una primera versión. Por hora cuando el alcance se va a descubrir en el camino, con un techo de gasto mensual y entregas quincenales que puedas revisar. Pagar por hora sin techo y sin entregas visibles es la peor combinación.

6. La salida

La cláusula que nadie quiere poner porque suena a desconfianza, y la que hace que nunca haga falta usarla.

Dice cómo termina la relación en buenos términos: qué se entrega —código, documentación, credenciales, respaldo completo de datos—, en cuántos días, y cuántas horas de empalme con el siguiente proveedor están incluidas. Veinte horas es un número razonable.

Su efecto real es sobre la negociación cotidiana. Cuando ambas partes saben que el cliente puede irse sin perder lo construido, la relación se sostiene en el trabajo y no en el encierro.

¿Qué pasa si quiero cambiar de proveedor a mitad del proyecto?

Depende de si previste la salida. Con el código en tu repositorio, la documentación de cómo se despliega y los accesos a tu nombre, cambiar de proveedor cuesta unas semanas de empalme. Sin eso, cuesta empezar de nuevo, y ese es exactamente el riesgo que la cláusula de salida elimina.

Cómo terminó el caso

Mal, y vale decirlo. No se pudo recuperar el código: estaba en una cuenta personal de un proveedor que no contestaba, y ninguna vía razonable llevaba ahí en menos de un año.

Lo que sí se pudo fue sacar los datos del servidor, que seguía accesible, y reconstruir el sistema con lo aprendido de tres años de operación. Costó 210,000 pesos y cuatro meses. Una cláusula de dos párrafos lo habría evitado por completo.