Contrato de desarrollo web: qué revisar antes de firmar
Un contrato de desarrollo web importa exactamente en dos ocasiones: cuando el proyecto va mal y cuando la relación termina. Ambas son previsibles, y un puñado de cláusulas determina cuánto le cuestan.
Esta guía cubre qué revisar antes de firmar, de qué le protege cada cláusula y los términos que merece la pena negociar.
Propiedad: la cláusula que no se puede arreglar después#
Todo lo demás en un contrato se puede renegociar. La propiedad no, una vez que la relación ha terminado mal.
- El código fuente es suyo con el pago final, sin ninguna condición de licencia continuada.
- El dominio está registrado a nombre de su organización, con sus datos de facturación, no los del proveedor.
- Las cuentas de alojamiento y de terceros están a su nombre, con quien desarrolla añadido como usuario.
- El contenido, las imágenes y los textos que usted aportó siguen siendo suyos; pregunte por lo que creen ellos.
- Las licencias de terceros —fuentes, plugins, imágenes de banco— se transfieren o se listan para que compre las suyas.
- Si algo se licencia en vez de transferirse, eso se declara de forma explícita con sus condiciones.
- Al terminar recibe el código, la base de datos y las credenciales en un plazo indicado.
«El código es suyo una vez pagada la factura final» es la frase que hay que buscar. «Le concedemos una licencia de uso del sitio» es otra cosa, y debería saber que la está eligiendo.
Alcance, cambios y revisiones#
Casi todas las disputas son disputas de alcance con otro nombre. Estas cláusulas deciden quién paga el desacuerdo.
| Cláusula | Qué buscar |
|---|---|
| Alcance del trabajo | Una lista concreta, adjunta como anexo, no un párrafo |
| Fuera de alcance | Una lista explícita de exclusiones: contenido, fotografía, carga, SEO |
| Proceso de cambios | Quién solicita, quién valora, cómo se aprueba, efecto sobre la fecha |
| Rondas de revisión | Un número, y el coste de una ronda adicional |
| Aceptación | Qué cuenta como aprobación y cuánto tiempo tiene para revisar |
| Obligaciones del cliente | Qué debe aportar, para cuándo, y el efecto si llega tarde |
| Retraso | Qué pasa en ambos lados; esto no debería ser unidireccional |
Pago, lanzamiento y soporte#
Vincular los pagos a cosas que puede ver protege a ambas partes; no es una petición hostil.
- Pagos por hitos contra entregables que pueda inspeccionar, no solo contra fechas.
- Una señal del 30 al 50 % es normal; el pago completo antes de empezar no lo es.
- Pago final al lanzar, no ante una aprobación interna que no puede verificar.
- Un periodo definido tras el lanzamiento para corregir defectos —habitualmente de 30 a 90 días— y qué significa defecto.
- La diferencia entre defecto (lo arreglan ellos) y petición nueva (paga usted), enunciada con ejemplos.
- Tiempos de respuesta por gravedad, si que el sitio se caiga importa a su negocio.
- Si el mantenimiento va incluido, es opcional o no existe, y su precio si lo contrata después.
Terminación y lo que la gente olvida#
Las cláusulas que solo importan una vez, y entonces importan mucho.
| Elemento | Por qué importa |
|---|---|
| Plazo de preaviso | Ambas partes deberían poder salir con un aviso razonable |
| Pago al terminar | Qué se debe por trabajo realizado pero no entregado |
| Traspaso | Código, base de datos, credenciales y documentación, en un plazo indicado |
| Límite de responsabilidad | Normalmente el valor del contrato; sepa cuál es |
| Protección de datos | Obligatoria si tratan datos personales por cuenta suya |
| Confidencialidad | Mutua, y debería sobrevivir a la terminación |
| Derechos de portafolio | Querrán mostrar el trabajo; acuerde las condiciones ahora |
| Ley aplicable | Importa mucho con un proveedor extranjero |
| Proceso de disputas | La mediación antes del litigio ahorra dinero a ambas partes |
Un proveedor cómodo con una cláusula de terminación clara suele ser un proveedor que espera que la relación vaya bien. La resistencia a ella merece una pregunta.
Preguntas frecuentes
¿Necesito un abogado para un contrato web?
Para un proyecto pequeño, un acuerdo escrito claro que cubra los puntos anteriores suele ser proporcionado. Para algo sustancial —una tienda, una aplicación o una construcción cuya pérdida dolería de verdad— un par de horas de revisión legal son baratas frente al valor en riesgo. Como mínimo, que lo lea alguien que no esté entusiasmado con el proyecto.
¿Es normal que el proveedor tenga el dominio?
Es común y no le conviene. El dominio debería estar registrado a nombre de su organización con sus datos de facturación; añada al proveedor como contacto técnico si necesita acceso. Los dominios en manos de un antiguo proveedor son una de las situaciones más fiablemente dolorosas de este sector.
¿Cuál es una señal razonable?
Del treinta al cincuenta por ciento, con el resto repartido entre hitos y el lanzamiento. Una señal es legítima: cubre el riesgo del proveedor de que usted desaparezca. El pago completo por adelantado traslada todo el riesgo a usted y no le deja ninguna palanca si el trabajo se atasca al ochenta por ciento.
¿Y si el proyecto se retrasa?
El contrato debería abordar el retraso en ambos lados, porque muy a menudo lo causan el contenido o las decisiones del cliente. Busque una cláusula que los distinga y establezca la consecuencia. Las cláusulas de penalización suenan tranquilizadoras y normalmente solo suben el precio, ya que el proveedor incorpora ese riesgo.
contrato desarrollo webcontrato diseño webpropiedad del códigoacuerdo webalcance del trabajochecklist contrato desarrollador
