Contrato de desarrollo de software: lo que debes revisar antes de pagar anticipo
Qué revisar en un contrato de desarrollo de software antes de pagar anticipo: alcance, entregables, cambios y propiedad del código.
El problema real
Un contrato de desarrollo de software suena como el trámite aburrido antes de empezar lo divertido. Tú quieres ver pantallas, flujos, usuarios entrando, dashboards prendidos. No quieres pasar tres días leyendo cláusulas que parecen escritas para dormir abogados.
Pero justo ahí es donde muchos proyectos se tuercen.
El founder paga el anticipo, la agencia arranca, todos están emocionados y dos semanas después aparece la primera pregunta incómoda: ¿eso estaba incluido? Luego viene la segunda: ¿quién es dueño del código? Y después la clásica: ¿por qué esto cuesta extra si para mí era obvio?
La mayoría de los problemas no nacen porque alguien sea mala persona. Nacen porque el contrato decía “desarrollo de plataforma web” como si eso significara lo mismo para todos. Spoiler: no significa lo mismo.
Un buen contrato de desarrollo de software no existe para meter miedo. Existe para que las dos partes sepan qué están comprando, qué están entregando y qué pasa cuando la realidad cambia, porque siempre cambia.
Por qué tantos contratos de software salen mal
El error más común es tratar el software como si fuera una compra cerrada, tipo “quiero una mesa de madera de 1.80 metros”. El problema es que una app no es una mesa. Una app es un montón de decisiones pequeñas que se descubren mientras se construye.
Qué pasa si el login necesita roles. Qué pasa si el usuario olvida su contraseña. Qué pasa si el admin necesita exportar datos. Qué pasa si Stripe rechaza un pago. Qué pasa si el cliente quiere cambiar un flujo porque al verlo en pantalla ya no le hace sentido.
Si el contrato no define cómo se manejan esas decisiones, cada cambio se vuelve una mini negociación. Y cuando hay presión, presupuesto limitado y fechas prometidas, esas mini negociaciones se sienten como pelea.
Lo que sí debería quedar claro antes del anticipo
Lo primero es el alcance. No solo una lista de módulos con nombres bonitos, sino una descripción clara de qué hace cada parte del sistema. “Panel de administración” no dice nada. Un panel puede ser una pantalla con tres métricas o un mini ERP disfrazado.
También necesitas saber qué no está incluido. Esto incomoda un poco, pero es sanísimo. Si la cotización no incluye diseño de marca, carga inicial de datos, redacción de textos, configuración avanzada de analytics o integraciones futuras, mejor saberlo antes de pagar que descubrirlo cuando ya estás a media construcción.
La propiedad del código también debe quedar cristalina. En un proyecto a medida, lo normal es que tú seas dueño del producto que pagaste, con la excepción razonable de librerías, herramientas internas o componentes reutilizables de la agencia. Pero eso tiene que estar escrito. No en una llamada. No en un “sí, claro”. Escrito.
Otro punto clave son los pagos. Un contrato sano no debería depender de fe ciega ni del “págame todo y nos vemos en tres meses”. Lo ideal es trabajar por hitos: anticipo para arrancar, pagos ligados a avances verificables y cierre contra entrega.
Cómo evitar broncas sin volverte abogado
No necesitas convertirte en experto legal para proteger tu proyecto. Necesitas hacer preguntas incómodas antes de que el dinero cambie de manos.
Pregunta cómo se aprueban cambios de alcance. Si mañana decides agregar una integración con HubSpot, ¿se cotiza aparte? ¿Se pausa algo? ¿Se cambia la fecha? La respuesta correcta no siempre es “sí, gratis”. La respuesta correcta es un proceso claro.
Pregunta qué cuenta como terminado. Una pantalla “lista” puede significar que se ve bien en la laptop del developer, que ya pasó QA, que funciona en móvil, que está conectada a datos reales o que ya fue aprobada por ti en staging. Si no hay criterio de aceptación, cada entrega se vuelve subjetiva.
Pregunta qué soporte hay después del lanzamiento. Siempre salen detalles. No necesariamente bugs gigantes, a veces son ajustes pequeños, configuración, permisos, correos que llegan a spam o usuarios que hacen cosas rarísimas. Define si hay garantía, por cuánto tiempo y qué cubre.
En DevAces preferimos hablar de estas cosas al principio, aunque baje un poco la emoción inicial. Es más fácil tener una conversación honesta antes de arrancar que rescatar un proyecto cuando ya todos están cansados.
Cierre
Un contrato de desarrollo de software no debería ser una trampa ni una novela legal. Debería ser el mapa mínimo para construir sin tener que adivinar intenciones.
Si estás por contratar una agencia, no revises solo el precio y la fecha de entrega. Revisa qué estás comprando realmente, quién se queda con qué, cómo se manejan cambios y qué pasa después del lanzamiento.
Si todo eso está claro, el proyecto empieza con mucha menos ansiedad. Y si no está claro, probablemente todavía no estás listo para pagar el anticipo.
Si quieres aterrizar el alcance de tu app antes de firmar algo, en DevAces podemos ayudarte a revisar la idea, separar lo esencial de lo inflado y convertirlo en un plan que no dependa de magia.