Cláusulas técnicas que o teu contrato de desenvolvemento debería incluír

O problema que ninguén ve ata que doe

Rematamos un proxecto complexo. O cliente pagou. Todos contentos.

Medio ano despois, o cliente decidiu levar o mantemento a outro provedor, e descubrimos que o contrato non dicía nada sobre quen controlaba o repositorio nin como se entregaban os accesos. O repositorio estaba na nosa conta, o cliente quería levalo con todo o dereito e non había un procedemento acordado. Unha cláusula de 2 liñas tería evitado unha discusión innecesaria.

Os contratos de desenvolvemento web adoitan ser modelos xenéricos de “prestación de servizos profesionais” que ignoran a natureza específica do software.

Estas son as 8 cláusulas técnicas que incluímos nos nosos contratos e que recomendamos a calquera que contrate desenvolvemento web, ou que o venda. Non substitúen o asesoramento xurídico, pero dinche que ten que estar enriba da mesa antes de asinar.

1. Definición precisa do alcance

O problema: “Desenvolver unha tenda en liña” pode significar desde un WooCommerce básico ata un marketplace multivendedor integrado cun ERP. A ambigüidade é a nai do conflito.

A cláusula: remitir a un anexo técnico que detalle as funcionalidades incluídas, as integracións concretas, o número de modelos de páxina, os fluxos de usuario cubertos e, de forma explícita, que queda fóra do alcance.

Exemplo: “O alcance inclúe: catálogo de ata 500 produtos con variacións, pagamento con Stripe e PayPal, xestión de pedidos desde o panel de administración e 5 páxinas informativas. Queda fóra do alcance: integración con ERP externo, subscricións recorrentes e app móbil nativa”.

Cambios durante o proxecto: fixa que pasa cando o cliente pide algo fóra do alcance. O sensato é un procedemento simple: solicitude por escrito, valoración de custo e prazo, e aprobación antes de executar.

2. Propiedade intelectual e licenzas

O problema: quen é o dono do código? Que pasa coas bibliotecas propias da axencia?

A cláusula: en España os dereitos morais de autor non se poden transferir, así que o que se pacta é a cesión dos dereitos de explotación (reprodución, distribución, transformación e comunicación pública) sobre o código desenvolvido para o proxecto. Indica se a cesión é exclusiva, o seu ámbito territorial e a súa duración, porque a lei é restritiva cando o contrato cala: se non se fixa un prazo, a cesión limítase a 5 anos.

E deixa fóra da cesión as bibliotecas de terceiros, coas súas propias licenzas, o código propio que a axencia reutiliza (licénzase, non se transfire) e o seu know-how.

Licenzas de terceiros: quen paga os plugins premium, as tipografías ou as fotos de stock, e a nome de quen se contratan.

3. Entregables e aceptación

O problema: “cando estea listo” non é unha data. Tampouco o é “cando o cliente estea satisfeito”, que equivale a un alcance infinito.

A cláusula: define os entregables (código fonte nun repositorio, documentación de despregamento, manual de usuario se procede) e os criterios de aceptación: funcionalidades operativas no contorno de probas e un período de revisión. Por exemplo, 5 días hábiles para enviar observacións; se non hai resposta, o entregable considérase aceptado.

Revisións e cambios: cantas roldas de revisión inclúe o prezo e que é un “axuste” fronte a un “cambio”. Un botón doutra cor é un axuste; engadir un campo ao formulario de pagamento é un cambio.

4. Aloxamento, accesos e datos

O problema: quen paga o aloxamento, quen ten acceso de administrador e que pasa cos datos se remata a relación?

A cláusula: especifica o modelo de aloxamento (xestionado pola axencia, polo cliente ou compartido), quen o configura e o paga, e quen accede ao panel, ao FTP, á base de datos e ás DNS. O recomendable é que o dominio e a conta de aloxamento estean sempre a nome do cliente.

Propiedade dos datos: os datos que introduce o cliente (contidos, produtos, usuarios) son seus. A axencia pode conservar copias durante o proxecto, pero non retelas indefinidamente despois da entrega.

Saída ordenada: se o cliente quere marchar, o contrato debe fixar o proceso: entrega de copias completas, transferencia de accesos e do repositorio, e un período de soporte de transición (por exemplo, 30 días, incluído ou facturado á parte). Os pasos prácticos están na nosa guía para cambiar de provedor web sen perdelo todo.

5. Mantemento e garantía

O problema: canto dura a garantía e onde remata un erro e empeza unha funcionalidade nova?

A cláusula: un período de garantía, habitualmente de 30 a 90 días desde o lanzamento, no que os erros se corrixen sen custo. Define que é un erro: unha funcionalidade que non opera segundo a especificación acordada. E exclúe os cambios de requisitos, os problemas causados por modificacións do cliente e as fallas de software de terceiros.

Mantemento: o correctivo (arranxar o que se rompe) pode ir incluído ou contratarse á parte; o evolutivo (engadir funcionalidades) é sempre desenvolvemento novo co seu propio orzamento. Se hai mantemento activo, fixa tempos de resposta por gravidade. Por exemplo: web caída en 4 horas, incidencia grave en 24 horas e menor en 3 días hábiles.

6. Confidencialidade e protección de datos (RXPD)

O problema: a axencia accede a datos dos clientes do seu cliente. Pode usalos para algo máis que o proxecto? Quen responde se hai unha brecha de seguridade?

A cláusula: a información do cliente non se comparte con terceiros nin se usa fóra do proxecto, e citalo como referencia ou caso de estudo require o seu permiso por escrito.

Protección de datos: se a axencia trata datos persoais por conta do cliente (por exemplo, ao manter unha web con rexistro de usuarios ou con acceso aos pedidos), o RXPD esixe un contrato de encargo do tratamento (artigo 28). Nel, o cliente figura como responsable e a axencia como encargada, e fíxanse as medidas de seguridade, as condicións para subcontratar e que se fai cos datos ao rematar. Máis detalle en onde se gardan realmente os datos dos teus clientes.

7. Limitación de responsabilidade

O problema: ata onde responde a axencia se o cliente perde vendas porque a web estivo caída?

A cláusula: o habitual é un teito igual ao importe total do contrato, excluíndo danos indirectos e lucro cesante. Esa limitación nunca pode amparar o dolo (o Código civil non o permite) e o razoable é que tampouco se aplique á culpa grave. Se o cliente é un consumidor, estas limitacións teñen pouco percorrido: a normativa de consumo considera abusivas as que recortan os seus dereitos. A axencia tampouco garante un 100% de dispoñibilidade nin responde do que non controla: caídas do aloxamento de terceiros, ataques DDoS ou fallas de API externas.

O risco de protección de datos adoita pactarse á parte, porque as sancións e reclamacións nesa materia poden superar con moito o valor do contrato.

8. Resolución de conflitos

A cláusula: unha escaleira de resolución para non acabar directamente nun preito longo e caro. Primeiro, negociación directa durante un prazo fixo; despois, mediación; e só se non funciona, arbitraxe ou tribunais. Indica tamén a lei aplicable e os tribunais competentes (por exemplo, lei española e xulgados de Pontevedra), tendo en conta que, se o cliente é un consumidor, estas cláusulas teñen límites legais.

Lista de revisión do contrato

Antes de asinar, comproba:

• Alcance definido con precisión, con exclusións explícitas e un procedemento para os cambios.
• Propiedade intelectual clara: que dereitos se ceden e que licenzas de terceiros se usan.
• Entregables especificados e criterios de aceptación obxectivos.
• Modelo de aloxamento, accesos e propiedade dos datos definidos.
• Garantía: período, que cobre e que non.
• Mantemento despois do lanzamento, con SLA se procede.
• Confidencialidade e contrato de encargo do tratamento de datos.
• Limitación de responsabilidade razoable.
• Resolución de conflitos e saída ordenada.

Se aínda estás a escoller provedor, completa esta lista coas 5 preguntas que deberías facer antes de contratar calquera desenvolvemento web.

Preguntas frecuentes

Necesito un avogado para isto?

Para contratos de importe significativo ou con datos sensibles, si. Un avogado con experiencia en tecnoloxía adaptará estas cláusulas ao teu caso. Para proxectos pequenos, usa estas pautas como lista de verificación para revisar o modelo que che propoñan.

Que pasa se o cliente non quere asinar un contrato formal?

É un sinal de alarma: non empeces a traballar. Un contrato non é desconfianza, é claridade, e se alguén foxe do papel, o problema non é o papel.

Canto debería durar a garantía?

Entre 30 e 90 días. Desconfía da “garantía de por vida”: o software non é unha cadeira, depende dun contorno que cambia constantemente, e o que se rompe por eses cambios é mantemento, non un erro de desenvolvemento.

Conclusión

Un contrato de desenvolvemento non serve para pelexar despois. Serve para non ter que pelexar.

A maioría dos conflitos non veñen da mala fe, senón de suposicións distintas: “Cría que o aloxamento ía incluído”. “Pensaba que os cambios de última hora non custaban extra”. “Non sabía que o código non era meu”.

Case todas esas discusións se evitan cunhas poucas páxinas ben escritas antes de empezar. Non fai falta un avogado para cada contrato, pero si saber que preguntar.

En Baqueiro revisamos a parte técnica dos contratos de desenvolvemento sabendo o que pasa despois no código e no servidor. Se estás a piques de asinar un ou queres poñer ao día o teu contrato estándar, falemos das túas cláusulas técnicas.