Notas: cláusulas de contrato que toda fundadora debe negociar

Este año una fundadora me reenvió un contrato de desarrollo para que le dijera si la tarifa le parecía razonable. La tarifa estaba bien. Lo que no estaba bien aparecía en la página cuatro, donde la agencia le concedía una licencia de uso del software en lugar de cederle la propiedad. Habría pagado una cifra de seis dígitos por permiso para usar su propio producto, y se habría enterado justo cuando intentara levantar una ronda o cambiar de equipo.

No es descuidada. Es una profesional seria que lee las cosas. Pero lo leyó como leemos casi todas los contratos: comprobando el número y el plazo, y dando por hecho que lo demás es texto estándar. No es estándar. Las cláusulas de contrato que deciden cuánto poder tienes son las que nadie te subraya en el correo de envío, y casi todas son negociables si preguntas antes de firmar en lugar de después.

Digo de entrada que nosotras construimos software y no somos abogadas, y que cualquier cosa con dinero de verdad encima merece un despacho que se dedique a esto. Lo que viene es lo que he aprendido sentada en los dos lados de estos documentos, como quien vende el trabajo y como quien lo compra.

Las cláusulas del contrato de desarrollo de app que más importan

Si no lees nada más, estas son las siete cláusulas del contrato de desarrollo de app que hay que revisar antes de firmar: cesión de derechos de propiedad intelectual al pago, titularidad de las cuentas y del repositorio, una definición escrita de aceptación, un control de cambios con tarifa acordada, pagos ligados a hitos, una cláusula de terminación con traspaso, y el contrato de encargo de tratamiento de datos. Todo lo que viene después explica por qué cada una se gana su sitio.

Ninguna es exótica. Aparecen ya en casi cualquier plantilla decente, y por eso mismo un contrato al que le falte una merece una pregunta.

Uno: cesión de derechos, no licencia

Esta es la cláusula que se lleva empresas por delante. Hay una diferencia enorme entre un contrato que te cede la propiedad intelectual del software y uno que te concede una licencia de uso. Las dos parecen razonables si lees rápido. Solo una sobrevive a una due diligence.

Lo que quieres es una cesión en exclusiva de los derechos de explotación sobre todo lo entregado, con efecto al pago completo. En España esa cesión tiene que ser expresa y por escrito, con el alcance, los medios y el ámbito detallados, según el texto refundido de la Ley de Propiedad Intelectual, así que un contrato que se limita a decir que el software es tuyo sin concretar nada es más débil de lo que parece. Pregunta directamente: el día que haya pagado todo, ¿soy dueña del código fuente, de los diseños y del modelo de datos, sin límite de tiempo ni de territorio?

Hay dos excepciones legítimas que yo aceptaría. Las agencias suelen reservarse sus herramientas internas genéricas que reutilizan entre clientes, y los componentes de código abierto vienen con su propia licencia que nadie puede ceder. Las dos están bien siempre que aparezcan nombradas y que lo que se reserven te quede licenciado de forma perpetua, para que no te lo puedan retirar más adelante.

Dos: las cuentas a tu nombre desde el primer día

Ser dueña sobre el papel no sirve de nada si no puedes llegar a lo que es tuyo. He visto una entrega atascarse tres semanas porque la cuenta de la App Store estaba a nombre de la agencia, el alojamiento se pagaba con su tarjeta y el código vivía en un repositorio privado de la cuenta personal de alguien.

Negocia lo contrario desde el principio. Las cuentas de Apple Developer y de Google Play, a nombre de tu empresa. La cuenta de la nube, de tu empresa, y la factura te llega a ti. El repositorio, de tu empresa, y la agencia tiene acceso, no al revés. Organizarlo en la semana uno no cuesta nada y deshacerlo en el mes nueve es un pequeño calvario. Además te dice algo útil de quien tienes enfrente, porque una buena agencia ya te lo habrá propuesto ella.

Tres: qué significa “terminado”

La causa más común de que un proyecto se tuerza no es el código malo. Es que cada parte tenía una imagen distinta de qué era estar terminado y nadie la escribió. Por eso la cláusula de aceptación importa más de lo que parece.

Quieres una definición de aceptación que remita a algo concreto: un documento de alcance acordado, una lista de flujos que tienen que funcionar, los dispositivos y versiones de sistema operativo soportados y un plazo de pruebas con duración fija. No quieres una aceptación automática por silencio a los pocos días, que es una cláusula que convierte tu despiste en conformidad. Y quieres que los defectos estén explícitos, es decir, un periodo de garantía posterior a la aceptación en el que los fallos de lo entregado se corrigen sin coste. De treinta a noventa días es una petición normal.

Si todavía no tienes escrito el documento de alcance, ese es el hueco de verdad, y conviene cerrarlo antes del contrato y no después. Nuestra guía de cómo escribir el brief para una agencia de apps es la versión de ese documento que yo querría como compradora.

Cuatro: control de cambios con precio puesto

Todos los proyectos cambian. Un contrato que finge lo contrario es ingenuo o es una trampa, porque el resultado por defecto es que cada cambio se convierte en una negociación que haces desde una posición débil con la obra ya empezada.

Pide tres cosas. Un proceso escrito de cómo se propone, se estima y se aprueba un cambio. Una tarifa aplicable a los cambios, acordada ahora y no presupuestada después. Y a poder ser un pequeño colchón en el calendario, para que los ajustes menores no disparen cada uno su ciclo de papeleo. La idea no es impedir los cambios. Es que sean aburridos.

Cinco: pagos por hitos, no por calendario

Pagar todos los meses pase lo que pase te traslada a ti todo el riesgo. No pagar nada hasta el final se lo traslada entero a la agencia, que es la razón por la que nadie sensato lo ofrece y por la que deberías desconfiar de quien lo haga.

El punto medio que funciona es un calendario ligado a hitos con entregables con nombre, y un pago final relevante retenido hasta la aceptación. Ese último tramo es tu única palanca real durante la entrega, así que no dejes que se quede en calderilla. Y desconfía de una señal muy alta sin ningún entregable asociado, que es un rasgo habitual de los acuerdos que acaban mal.

Seis: la cláusula de salida que esperas no usar

Lee la parte de terminación como si la relación ya se hubiera roto, porque esa es la única situación en la que se va a leer.

Las preguntas que hay que responder antes de firmar: ¿puede cualquiera de las dos partes terminar por conveniencia, y con cuánto preaviso? ¿Qué recibes al terminar, e incluye eso de forma explícita el código fuente actual, los diseños, las credenciales y la documentación? ¿Hay penalización, y es proporcionada? ¿Y hay obligación de traspaso con un número de días de soporte, porque código entregado sin explicación es solo un poco mejor que nada?

Miraría también la limitación de responsabilidad, que casi siempre topa la exposición de la agencia en los honorarios cobrados. Es lo normal y en la mayoría de casos no pelearía por ello. Simplemente sabría que está ahí, porque te dice cuál es el techo de cualquier reparación que puedas obtener, y eso debería influir en cuánto te apoyas en el contrato frente a cuánto te apoyas en elegir bien. De elegir bien va las banderas rojas al elegir agencia de apps, que es el mismo argumento llegando antes en el proceso.

Siete: la cláusula de datos, que no es opcional

Si la agencia va a tratar datos personales de tus usuarios, y lo va a hacer casi seguro durante las pruebas y el soporte, el RGPD exige un contrato de encargo de tratamiento por escrito entre tú, como responsable, y ella, como encargada, con un contenido mínimo concreto. La Agencia Española de Protección de Datos publica orientación sobre qué debe incluir.

Esta no es tanto una negociación como un requisito, y la señal útil es cómo reacciona la agencia cuando lo sacas. Quien lo tiene preparado ya ha pensado antes en los datos de tus usuarias. Quien no lo ha oído nunca te está contando algo del resto del proyecto, y suele reaparecer en cómo lleva el trabajo de cumplimiento que describimos en cómo cumplir el RGPD en tu app.

Qué haría distinto

Durante mucho tiempo traté los contratos como la parte aburrida del final, un trámite una vez terminadas las conversaciones interesantes. Estaba equivocada, y no por el motivo que parece. Negociar estas cláusulas es la forma más rápida de descubrir cómo piensa la otra parte. Aprendes más de una agencia en los veinte minutos que dedica a explicarte su cláusula de propiedad intelectual que en una hora de casos de éxito.

Así que mi consejo honesto es sacar las siete cláusulas del contrato de desarrollo de app antes de cerrar la propuesta, y tratar la conversación como diligencia y no como regateo. La fundadora del principio pidió la cesión al pago y la consiguió en un día, porque la agencia usaba una plantilla que nunca había mirado con calma. Casi siempre es eso y no mala fe. Pero la plantilla no cambia si no la cuestionas.

Si prefieres ver una propuesta que ya trae la propiedad, los accesos, la aceptación y la salida escritos como cuenta este artículo, cuéntanos tu proyecto y podrás leer la nuestra antes de hablar con nadie más. Y si todavía estás comparando, cómo evaluar el portfolio de una agencia cubre el paso justo anterior a este.