Qué debe incluir un contrato de desarrollo de app o web

Un contrato de desarrollo de app o web debe dejar claro, por escrito, cinco cosas: qué se va a construir exactamente, cuánto cuesta y cómo se paga, de quién es el código al terminar, qué plazos se comprometen y qué pasa si algo cambia por el camino. Si alguno de estos puntos falta o queda ambiguo, es donde suelen aparecer los conflictos.

En los proyectos que hago reviso el contrato con el cliente antes de empezar, línea por línea, porque es la mejor forma de evitar sorpresas más adelante. No hace falta que sea un documento de diez páginas lleno de términos legales. Hace falta que sea concreto.

Por qué un contrato importa aunque confíes en quien te desarrolla

No es una cuestión de desconfianza. Es que, sin un documento, cualquier desacuerdo sobre qué se incluía o qué se entendía por "terminado" se resuelve a base de memoria y buena voluntad. Un contrato claro protege a las dos partes: a ti, porque sabes qué vas a recibir y cuándo; a quien desarrolla, porque sabe qué no está incluido y puede cobrar aparte si pides algo nuevo.

Esto es especialmente importante si trabajas con un freelance o un estudio pequeño, donde no hay un departamento legal que redacte el documento por ti. Si quieres comparar esa opción con una agencia grande, tengo un artículo específico sobre freelance o agencia para tu web o app.

Qué debe definir el alcance del proyecto

El alcance es la parte que más dinero ahorra o más dinero cuesta, según esté bien o mal escrita. Debe incluir:

• Qué pantallas, secciones o funciones concretas entran en la primera entrega.
• Para cuántos idiomas, plataformas (iOS, Android, web) o navegadores se construye.
• Qué integraciones se incluyen (pagos, email, un CRM, redes sociales) y cuáles no.
• Quién pone los contenidos: textos, fotos, vídeos, traducciones.
• Qué queda explícitamente fuera, para que no se asuma por defecto.

Un contrato que solo dice "desarrollo de una app para el negocio" no protege a nadie. Uno que dice "app iOS y Android con registro, catálogo de hasta 50 productos, carrito y pago con tarjeta, en español" sí lo hace. Si todavía no tienes claro qué pedir en esta fase, antes del contrato viene el presupuesto: te explico cómo prepararlo en qué pedir en un presupuesto de app o web.

Cómo debe quedar el precio y la forma de pago

El precio puede estar cerrado (una cifra fija por todo el alcance) o calculado por horas o por fases. Los dos modelos son legítimos, pero el contrato debe decir cuál es y qué pasa si el trabajo se alarga.

Con precio cerrado, lo normal en el mercado español es repartir el pago en dos o tres hitos: un adelanto al empezar, un pago intermedio si el proyecto dura varias semanas y el resto en la entrega. En el paquete de Fluxer Labs, por ejemplo, app, web y panel de gestión en cuatro semanas se paga 3.000 EUR con un 50% al empezar y un 50% en la entrega, con el alcance cerrado desde el primer día.

Con precio por horas, el contrato debe fijar una tarifa, una estimación de horas y un aviso obligatorio antes de superar un margen (por ejemplo, un 10-15% sobre lo estimado). Sin ese límite, firmas un cheque en blanco.

De quién es el código, el dominio y las cuentas al terminar

Esto es, probablemente, la cláusula que más se pasa por alto y la que más importa a largo plazo. El contrato debe decir, sin rodeos, que el código fuente, el dominio y las cuentas de App Store, Google Play o del hosting quedan a tu nombre al terminar el proyecto, no a nombre de quien lo desarrolla.

Hay estudios que se quedan con el control del dominio o las cuentas de desarrollador "por comodidad" y eso te deja atado a ellos para cualquier cambio futuro, incluso uno pequeño. Pide siempre que quede explícito que, al pagar la entrega final, recibes acceso completo y la titularidad de todo lo anterior.

Plazos, entregas parciales y qué pasa si algo se retrasa

Un buen contrato no se limita a poner una fecha final. Define entregas intermedias (por ejemplo, una versión navegable cada semana) para que puedas comprobar que el proyecto avanza como esperabas, no solo al final. También debe explicar qué pasa si el retraso es por cambios que pides tú a mitad de camino, frente a un retraso por parte de quien desarrolla.

Si quieres saber qué es razonable esperar en cada semana de un proyecto típico, lo cubro en qué esperar semana a semana en el desarrollo de una app o web.

Qué cubre el soporte después de la entrega

Casi ningún proyecto termina sin ningún ajuste tras la entrega: un texto que cambiar, un pequeño fallo que aparece con uso real. El contrato debe decir cuántos días de soporte gratuito están incluidos tras la entrega y qué cubre exactamente (corrección de errores) frente a lo que no cubre (funciones nuevas). Después de ese periodo, debe quedar claro si existe un mantenimiento mensual opcional o si cada mejora se presupuesta por separado.

Preguntas frecuentes

¿Necesito un abogado para revisar el contrato?

No es obligatorio para proyectos pequeños, pero si el importe es alto o el proyecto es complejo, una revisión rápida de un abogado o gestoría de confianza suele costar poco frente al riesgo de un contrato ambiguo. Como mínimo, no firmes nada que no entiendas línea por línea.

¿Qué pasa si pido cambios que no estaban en el contrato?

Un contrato bien escrito no lo prohíbe, pero establece que cualquier función nueva fuera del alcance original se valora y se acuerda aparte, con su propio coste y plazo, antes de añadirla al proyecto.

¿Es normal pagar un adelanto antes de empezar?

Sí. Un adelanto del 30-50% al firmar es habitual en desarrollo de software en España, tanto con freelances como con agencias. Lo que no es normal es pagar el 100% por adelantado sin ningún hito ni entrega parcial de por medio.

Si estás preparando un proyecto y quieres un contrato claro desde el primer día, con alcance y precio cerrados antes de empezar, puedes ver el paquete de app, web y panel por 3.000 EUR en 4 semanas o escribirme directamente para hablar de tu caso.