Por qué los contratos genéricos no funcionan para desarrollo web
El desarrollo de software tiene particularidades que un contrato de servicios estándar no cubre: ¿quién es propietario del código una vez entregado? ¿Qué pasa con los bugs que aparecen después de la entrega? ¿Quién gestiona el hosting y el dominio? ¿Qué incluye exactamente "terminar el proyecto"?
Estas preguntas, sin respuesta clara en el contrato, generan los conflictos más habituales entre desarrolladores y clientes.
Cláusulas específicas para proyectos de desarrollo web
1. Definición del alcance técnico
El mayor problema en desarrollo es el scope creep. El contrato debe incluir un documento técnico adjunto (brief o especificación funcional) que defina exactamente qué páginas, funcionalidades, integraciones y dispositivos están incluidos. Todo lo que no está en ese documento es trabajo adicional con coste adicional.
2. Propiedad del código
¿El cliente es propietario del código desde el inicio, al pagar el primer hito, o solo al pagar el total? ¿Qué pasa con las librerías y componentes de terceros? Estas son las preguntas que debes responder en el contrato. Lo más habitual:
- El código desarrollado específicamente para el proyecto pasa a ser del cliente al pagar el 100%
- Las librerías de terceros tienen sus propias licencias que el cliente acepta
- El desarrollador puede conservar componentes genéricos reutilizables
3. Entorno de desarrollo y entrega
Especifica en qué entorno se desarrolla, cómo se entrega (repositorio Git, servidor de staging, FTP) y en qué estado debe quedar el proyecto al finalizar: documentación incluida, credenciales entregadas, dependencias actualizadas.
4. Bugs y garantía post-entrega
Define claramente la diferencia entre bug (funcionalidad que no funciona según lo especificado) y cambio (nueva funcionalidad o modificación). Los bugs dentro de un período de garantía (habitual: 30-60 días) se corrigen sin coste. Los cambios tienen coste adicional.
5. Hosting, dominio y mantenimiento
¿El desarrollador gestiona el hosting o solo entrega el código? ¿Quién renueva el dominio? ¿Hay un contrato de mantenimiento separado? Si el desarrollador gestiona la infraestructura, debe quedar claro qué pasa si el cliente quiere migrar a otro proveedor.
6. Acceso a sistemas del cliente
Si el desarrollador accede a los sistemas del cliente (cuentas de hosting, bases de datos, paneles de administración), incluye una cláusula de confidencialidad específica y de responsabilidad limitada.
7. Plazos con hitos verificables
Evita "el proyecto se entregará en 6 semanas". En su lugar: "entrega del diseño aprobado el día X, entrega de frontend el día Y, entrega de backend el día Z". Los plazos deben estar vinculados a entregas verificables, no a semanas abstractas.
8. Pagos vinculados a hitos
La estructura más habitual y la que mejor protege a ambas partes: 30-50% al inicio, pagos parciales en cada hito, 10-20% a la entrega final aceptada. Nunca trabajes sin anticipo.
Cómo compartir el contrato antes de empezar
El contrato de desarrollo debe ser aceptado antes de que comience cualquier trabajo. Enviar el PDF por email y esperar una respuesta no genera la evidencia que necesitas. Con KLINQS puedes requerir aceptación explícita antes de que el cliente acceda al contrato, con un registro verificable de quién aceptó y cuándo.