Cláusulas técnicas que tu contrato de desarrollo debería incluir

El problema que nadie ve hasta que duele

Terminamos un proyecto complejo. El cliente pagó. Todos contentos.

Medio año después, el cliente decidió llevarse el mantenimiento a otro proveedor, y descubrimos que el contrato no decía nada sobre quién controlaba el repositorio ni cómo se entregaban los accesos. El repositorio estaba en nuestra cuenta, el cliente quería llevárselo con todo el derecho y no había un procedimiento acordado. Una cláusula de 2 líneas habría evitado una discusión innecesaria.

Los contratos de desarrollo web suelen ser plantillas genéricas de «prestación de servicios profesionales» que ignoran la naturaleza específica del software.

Estas son las 8 cláusulas técnicas que incluimos en nuestros contratos y que recomendamos a cualquiera que contrate desarrollo web, o que lo venda. No sustituyen al asesoramiento jurídico, pero te dicen qué tiene que estar sobre la mesa antes de firmar.

1. Definición precisa del alcance

El problema: «Desarrollar una tienda online» puede significar desde un WooCommerce básico hasta un marketplace multivendedor integrado con un ERP. La ambigüedad es la madre del conflicto.

La cláusula: remitir a un anexo técnico que detalle las funcionalidades incluidas, las integraciones concretas, el número de plantillas de página, los flujos de usuario cubiertos y, de forma explícita, qué queda fuera del alcance.

Ejemplo: «El alcance incluye: catálogo de hasta 500 productos con variaciones, pago con Stripe y PayPal, gestión de pedidos desde el panel de administración y 5 páginas informativas. Queda fuera del alcance: integración con ERP externo, suscripciones recurrentes y app móvil nativa».

Cambios durante el proyecto: fija qué pasa cuando el cliente pide algo fuera del alcance. Lo sensato es un procedimiento simple: solicitud por escrito, valoración de coste y plazo, y aprobación antes de ejecutar.

2. Propiedad intelectual y licencias

El problema: ¿quién es el dueño del código? ¿Qué pasa con las librerías propias de la agencia?

La cláusula: en España los derechos morales de autor no se pueden transferir, así que lo que se pacta es la cesión de los derechos de explotación (reproducción, distribución, transformación y comunicación pública) sobre el código desarrollado para el proyecto. Indica si la cesión es exclusiva, su ámbito territorial y su duración, porque la ley es restrictiva cuando el contrato calla: si no se fija un plazo, la cesión se limita a 5 años.

Y deja fuera de la cesión las librerías de terceros, con sus propias licencias, el código propio que la agencia reutiliza (se licencia, no se transfiere) y su know-how.

Licencias de terceros: quién paga los plugins premium, las tipografías o las fotos de stock, y a nombre de quién se contratan.

3. Entregables y aceptación

El problema: «cuando esté listo» no es una fecha. Tampoco lo es «cuando el cliente esté satisfecho», que equivale a un alcance infinito.

La cláusula: define los entregables (código fuente en un repositorio, documentación de despliegue, manual de usuario si procede) y los criterios de aceptación: funcionalidades operativas en el entorno de pruebas y un periodo de revisión. Por ejemplo, 5 días hábiles para enviar observaciones; si no hay respuesta, el entregable se considera aceptado.

Revisiones y cambios: cuántas rondas de revisión incluye el precio y qué es un «ajuste» frente a un «cambio». Un botón de otro color es un ajuste; añadir un campo al formulario de pago es un cambio.

4. Alojamiento, accesos y datos

El problema: ¿quién paga el hosting, quién tiene acceso de administrador y qué pasa con los datos si termina la relación?

La cláusula: especifica el modelo de hosting (gestionado por la agencia, por el cliente o compartido), quién lo configura y lo paga, y quién accede al panel, al FTP, a la base de datos y a las DNS. Lo recomendable es que el dominio y la cuenta de hosting estén siempre a nombre del cliente.

Propiedad de los datos: los datos que introduce el cliente (contenidos, productos, usuarios) son suyos. La agencia puede conservar copias durante el proyecto, pero no retenerlas indefinidamente tras la entrega.

Salida ordenada: si el cliente quiere irse, el contrato debe fijar el proceso: entrega de copias completas, transferencia de accesos y del repositorio, y un periodo de soporte de transición (por ejemplo, 30 días, incluido o facturado aparte). Los pasos prácticos están en nuestra guía para cambiar de proveedor web sin perderlo todo.

5. Mantenimiento y garantía

El problema: ¿cuánto dura la garantía y dónde acaba un error y empieza una funcionalidad nueva?

La cláusula: un periodo de garantía, habitualmente de 30 a 90 días desde el lanzamiento, en el que los errores se corrigen sin coste. Define qué es un error: una funcionalidad que no opera según la especificación acordada. Y excluye los cambios de requisitos, los problemas causados por modificaciones del cliente y los fallos de software de terceros.

Mantenimiento: el correctivo (arreglar lo que se rompe) puede ir incluido o contratarse aparte; el evolutivo (añadir funcionalidades) es siempre desarrollo nuevo con su propio presupuesto. Si hay mantenimiento activo, fija tiempos de respuesta por gravedad. Por ejemplo: web caída en 4 horas, incidencia grave en 24 horas y menor en 3 días hábiles.

6. Confidencialidad y protección de datos (RGPD)

El problema: la agencia accede a datos de los clientes de su cliente. ¿Puede usarlos para algo más que el proyecto? ¿Quién responde si hay una brecha de seguridad?

La cláusula: la información del cliente no se comparte con terceros ni se usa fuera del proyecto, y citarlo como referencia o caso de estudio requiere su permiso por escrito.

Protección de datos: si la agencia trata datos personales por cuenta del cliente (por ejemplo, al mantener una web con registro de usuarios o con acceso a los pedidos), el RGPD exige un contrato de encargo del tratamiento (artículo 28). En él, el cliente figura como responsable y la agencia como encargada, y se fijan las medidas de seguridad, las condiciones para subcontratar y qué se hace con los datos al terminar. Más detalle en dónde se guardan realmente los datos de tus clientes.

7. Limitación de responsabilidad

El problema: ¿hasta dónde responde la agencia si el cliente pierde ventas porque la web estuvo caída?

La cláusula: lo habitual es un tope igual al importe total del contrato, excluyendo daños indirectos y lucro cesante. Esa limitación nunca puede amparar el dolo (el Código Civil no lo permite) y lo razonable es que tampoco se aplique a la culpa grave. Si el cliente es un consumidor, estas limitaciones tienen poco recorrido: la normativa de consumo considera abusivas las que recortan sus derechos. La agencia tampoco garantiza un 100% de disponibilidad ni responde de lo que no controla: caídas del hosting de terceros, ataques DDoS o fallos de APIs externas.

El riesgo de protección de datos suele pactarse aparte, porque las sanciones y reclamaciones en esa materia pueden superar con mucho el valor del contrato.

8. Resolución de conflictos

La cláusula: una escalera de resolución para no acabar directamente en un pleito largo y caro. Primero, negociación directa durante un plazo fijo; después, mediación; y solo si no funciona, arbitraje o tribunales. Indica también la ley aplicable y los tribunales competentes (por ejemplo, ley española y juzgados de Pontevedra), teniendo en cuenta que, si el cliente es un consumidor, estas cláusulas tienen límites legales.

Checklist de revisión del contrato

Antes de firmar, comprueba:

• Alcance definido con precisión, con exclusiones explícitas y un procedimiento para los cambios.
• Propiedad intelectual clara: qué derechos se ceden y qué licencias de terceros se usan.
• Entregables especificados y criterios de aceptación objetivos.
• Modelo de hosting, accesos y propiedad de los datos definidos.
• Garantía: periodo, qué cubre y qué no.
• Mantenimiento tras el lanzamiento, con SLA si procede.
• Confidencialidad y contrato de encargo del tratamiento de datos.
• Limitación de responsabilidad razonable.
• Resolución de conflictos y salida ordenada.

Si todavía estás eligiendo proveedor, completa esta lista con las 5 preguntas que deberías hacer antes de contratar cualquier desarrollo web.

Preguntas frecuentes

¿Necesito un abogado para esto?

Para contratos de importe significativo o con datos sensibles, sí. Un abogado con experiencia en tecnología adaptará estas cláusulas a tu caso. Para proyectos pequeños, usa estas pautas como checklist para revisar la plantilla que te propongan.

¿Qué pasa si el cliente no quiere firmar un contrato formal?

Es una señal de alarma: no empieces a trabajar. Un contrato no es desconfianza, es claridad, y si alguien huye del papel, el problema no es el papel.

¿Cuánto debería durar la garantía?

Entre 30 y 90 días. Desconfía de la «garantía de por vida»: el software no es una silla, depende de un entorno que cambia constantemente, y lo que se rompe por esos cambios es mantenimiento, no un error de desarrollo.

Conclusión

Un contrato de desarrollo no sirve para pelear después. Sirve para no tener que pelear.

La mayoría de los conflictos no vienen de la mala fe, sino de suposiciones distintas: «Creía que el hosting iba incluido». «Pensaba que los cambios de última hora no costaban extra». «No sabía que el código no era mío».

Casi todas esas discusiones se evitan con unas pocas páginas bien escritas antes de empezar. No hace falta un abogado para cada contrato, pero sí saber qué preguntar.

En Baqueiro revisamos la parte técnica de los contratos de desarrollo sabiendo lo que pasa después en el código y en el servidor. Si estás a punto de firmar uno o quieres poner al día tu contrato estándar, hablemos de tus cláusulas técnicas.