Contrato para desarrollador web freelance: cláusulas clave para evitar conflictos

Por qué el desarrollo web necesita un contrato específico

Un contrato genérico de servicios no cubre las particularidades del desarrollo web. El software tiene características únicas que generan conflictos recurrentes: cambios de alcance constantes, dudas sobre quién es dueño del código, peticiones de soporte indefinido tras la entrega, y proyectos que se alargan sin una fecha de cierre clara.

Un contrato bien redactado para un proyecto web no solo te protege: también establece expectativas claras desde el primer día, reduce las disputas a mitad de proyecto y te permite trabajar con más tranquilidad.

Las cláusulas esenciales para desarrolladores web

1. Especificación técnica detallada

Es la cláusula más importante y la que más conflictos evita. Define con precisión:

• Stack tecnológico: lenguajes, frameworks, bases de datos, servicios de terceros
• Funcionalidades incluidas: lista cada módulo o pantalla
• Funcionalidades excluidas: específica lo que no está en el alcance
• Criterios de aceptación: cómo se define que algo «está terminado»
• Número de revisiones: cuántas rondas de feedback están incluidas
• Soporte post-lanzamiento: si está incluido, por cuánto tiempo y qué cubre

Sin una especificación técnica firmada, el cliente siempre podrá alegar que «eso debería estar incluido».

2. Propiedad intelectual del código

Esta cláusula es crítica. En España, la Ley de Propiedad Intelectual establece que el autor del código es quien lo escribe, salvo cesión expresa. Tienes varias opciones:

Opción A — Cesión total de derechos: el cliente adquiere todos los derechos sobre el código entregado. Solo aplica al código específico del proyecto, no a librerías, frameworks o componentes genéricos que uses.

Opción B — Licencia de uso: el cliente puede usar el código para el proyecto acordado, pero no puede revenderlo, copiarlo para otros proyectos ni modificarlo sin tu autorización. Tú retienes los derechos.

Opción C — Derechos condicionados al pago: los derechos se transfieren al cliente solo cuando se completa el pago total. Hasta entonces, el cliente tiene una licencia provisional revocable. Esta es la opción más protectora para el desarrollador.

Especifica también qué ocurre con componentes de terceros (open source, librerías con licencia comercial): quién paga las licencias y quién las gestiona.

3. Control de versiones y entrega del código fuente

Define:

• En qué repositorio se desarrolla el proyecto (GitHub, GitLab, etc.)
• Quién tiene acceso y en qué momento
• Qué se entrega al final: repositorio completo, rama main, documentación técnica
• Si entregas el entorno de desarrollo o solo el código fuente

Muchos desarrolladores asumen que el cliente sabe gestionar un repositorio. Especificarlo evita malentendidos.

4. Garantía y período de mantenimiento

Es habitual incluir un período de garantía tras la entrega (normalmente 30–90 días) durante el cual corriges bugs sin coste adicional. Define claramente:

• Qué es un bug (error en el código que impide el funcionamiento correcto)
• Qué es un cambio de alcance (nueva funcionalidad o modificación del diseño)
• Los bugs se corrigen gratis dentro de la garantía; los cambios de alcance se presupuestan aparte

El mantenimiento continuado (actualizaciones, nuevas funcionalidades, soporte técnico) debe ir en un contrato de mantenimiento separado con facturación mensual.

5. Dependencias del cliente y gestión de retrasos

Los proyectos web dependen de que el cliente entregue materiales: contenidos, imágenes, accesos, decisiones de diseño. Si el cliente retrasa estas entregas, el proyecto se retrasa.

Incluye una cláusula que establezca que:

• El plazo de entrega queda suspendido mientras el cliente no proporcione los materiales o aprobaciones requeridas
• Si el retraso supera X días, tienes derecho a reprogramar el proyecto y posiblemente facturar por el tiempo de reserva

6. Infraestructura y hosting

Define claramente quién contrata y paga:

• El servidor o servicio de hosting
• El dominio
• Las licencias de software o servicios de terceros (Stripe, SendGrid, etc.)
• Los certificados SSL

Y en qué entorno se entrega el proyecto: ¿lo despliegas tú en producción o solo entregas el código?

7. Accesos y seguridad

Si el cliente te da acceso a sistemas, bases de datos o infraestructura existente:

• Documenta qué accesos recibes y cuándo se revocan
• Incluye una cláusula de confidencialidad sobre los datos a los que accedes
• Especifica que no eres responsable de problemas preexistentes en la infraestructura

El problema del «scope creep» en desarrollo web

El «scope creep» —el crecimiento no controlado del alcance— es la principal causa de proyectos no rentables en desarrollo web. El cliente empieza pidiendo «una pequeña modificación» y semanas después el proyecto ha duplicado su alcance sin que el precio haya cambiado.

La solución contractual:

1. Especificación inicial firmada: cualquier cosa fuera de ella es un cambio de alcance
2. Proceso de gestión de cambios: cualquier cambio requiere una solicitud escrita con descripción, tiempo estimado y precio adicional
3. Aprobación antes de ejecutar: no ejecutas ningún cambio hasta tener la aprobación escrita del cliente

Muchos desarrolladores tienen miedo de parecer rígidos. En realidad, un proceso claro de gestión de cambios transmite profesionalidad y protege tanto al desarrollador como al cliente.

Hitos de pago para proyectos web

La estructura de pagos recomendada para proyectos web es:

• 30–40% al inicio (señal para reservar el proyecto y cubrir los primeros costes)
• 30–40% en un hito intermedio (prototipo funcional, versión beta, primera fase completada)
• 20–30% final (tras la entrega y aprobación, antes del despliegue en producción)

Regla de oro: nunca despliega en producción antes de cobrar el pago final. Una vez que el cliente tiene el proyecto en su dominio y funcionando, tu principal palanca de negociación desaparece.

Genera tu contrato de desarrollo web con todas las cláusulas necesarias usando Firmia — gratis para empezar.