Análisis de una propuesta de agencia de software: 12 cláusulas que cambian precio, alcance y propiedad

Para revisar bien una propuesta de desarrollo de software, ignora el acabado comercial durante diez minutos. Léela como un mapa de quién paga cuando falla una hipótesis, quién decide si el trabajo está terminado y quién puede operar el producto cuando la agencia ya no esté. La cifra principal solo es comparable cuando esas tres preguntas tienen respuesta.

Esta es una herramienta de revisión comercial y técnica, no asesoramiento jurídico. El ejemplo es completamente ficticio y combina fórmulas habituales en propuestas reales. Pide a un abogado cualificado en la ley aplicable que revise responsabilidad, garantía, propiedad intelectual, terminación y exigibilidad.

Descarga gratis la rúbrica imprimible de 24 puntos. Incluye scorecard, hard stops, hoja de precio comparable y doce preguntas para el redline. El PDF está actualmente en inglés; toda la explicación está localizada aquí.

Cómo revisar una propuesta de software en cuatro pasadas

1. Pasada comercial: qué libera un pago, qué queda excluido y qué puede aumentar el precio.
2. Pasada de entrega: qué artefactos se crean, cómo se aceptan y qué significa «terminado».
3. Pasada de propiedad y operación: quién controla código, datos, cuentas, infraestructura y licencias, y si tu equipo puede asumirlos.
4. Pasada de excepciones: qué ocurre ante retraso, incidente, disputa, cambio de personal o terminación.

Marca palabras como «razonable», «estándar del sector», «a tiempo», «sustancial» y «según esfuerzo». No son necesariamente malas, pero necesitan un responsable, una evidencia, un plazo y una consecuencia. Sin eso, el significado se negocia cuando el proyecto ya tiene dinero y calendario comprometidos.

Por qué esta página no compite con la guía para elegir agencia

Nuestra guía para elegir una agencia de software responde a quién contratar: seniority, referencias, modelo de trabajo, comunicación y traspaso. Este artículo empieza después. Responde cómo inspeccionar el documento que envía la agencia seleccionada. Primero eliges proveedor. Después revisas alcance, precio y derechos en su propuesta o Statement of Work.

La propuesta ficticia: «Portal de clientes Northstar»

Parece concreta: una cifra, un plazo y cuatro grupos de features. Sin embargo, las cláusulas abiertas pueden añadir meses de trabajo, plataformas recurrentes y una migración completa.

Las doce cláusulas, de un vistazo

1. Criterios de aceptación: ¿qué libera el pago?

La propuesta dice: «El cliente aceptará cada hito en cinco días laborables. Sin respuesta, el hito se considerará aceptado».

Por qué es una señal de alerta: el plazo está claro; la prueba no. Sin escenarios, datos, entorno, tolerancias y severidades, la agencia puede considerar una demo como entrega mientras el cliente espera un resultado listo para operar. La aceptación por silencio agrava esa diferencia.

Redline: vincula cada hito con escenarios, datos de prueba, entorno, responsable y ventana de UAT. Define defectos bloqueantes, críticos y menores, subsanación y retest. Indica qué pago vence tras la aceptación y qué ocurre ante rechazo justificado.

Prueba de dos puntos: una persona ajena puede determinar si el hito ha pasado sin interpretar el ambiente de la reunión.

2. Propiedad intelectual: ¿compras el producto o solo acceso?

La propuesta dice: «Todos los entregables a medida pasarán al cliente tras el pago completo. Las herramientas previas y el know-how genérico seguirán siendo de la agencia».

Por qué es una señal de alerta: «entregable», «herramienta» y «genérico» no están definidos. No sabemos si se transfieren código fuente, infraestructura, tests, diseños, prompts, modelos de datos, documentación y trabajo parcial. Una salida antes del pago final puede dejar al cliente sin derecho utilizable sobre hitos ya pagados.

Redline: separa materiales del cliente, IP previa, IP creada y terceros. Lista artefactos, momento de transferencia, territorio, duración, modificación y sublicencia. La IP previa necesaria necesita una licencia perpetua y suficientemente amplia. Exige garantías sobre empleados y subcontratistas.

El European IP Helpdesk distingue asignación y licencia. La redacción debe coincidir con el resultado económico que buscas.

3. Solicitudes de cambio: ¿cómo se aprueba trabajo adicional?

La propuesta dice: «Los cambios y requisitos adicionales se facturarán según esfuerzo a la tarifa diaria vigente».

Por qué es una señal de alerta: no hay baseline, formulario, análisis de impacto ni aprobador. Un bug puede convertirse en requisito nuevo, o el trabajo puede empezar antes de que el cliente conozca precio y plazo.

Redline: cada cambio describe alcance original y nuevo, hipótesis, precio, calendario, dependencias y aceptación. Solo personas nombradas aprueban por escrito antes de empezar. Corregir un defecto para cumplir lo ya acordado no es un cambio.

Para entender cómo el modelo comercial mueve este riesgo, consulta precio fijo vs T&M: el scope creep en cifras.

4. Garantía: ¿quién paga la reparación?

La propuesta dice: «La agencia corregirá bugs críticos sin coste durante 30 días después del go-live».

Por qué es una señal de alerta: «crítico», «bug» y «go-live» no están definidos. Faltan respuesta, remedio, retest y defectos de hitos anteriores. Cualquier desviación puede etiquetarse como mantenimiento o mejora.

Redline: define defecto como incumplimiento de especificación, aceptación o definición de terminado. Fija inicio, duración, severidad, respuesta, remedio, retest y escalado. Separa corrección de defectos, mantenimiento y enhancements.

5. Dependencias: ¿quién posee el riesgo de retraso?

La propuesta dice: «El calendario depende de la colaboración puntual del cliente. Los retrasos del cliente desplazarán todas las fechas».

Por qué es una señal de alerta: la obligación es unilateral e ilimitada. Cualquier respuesta tardía puede desplazar todo, aunque no esté en el camino crítico. La agencia no tiene deber equivalente de avisar pronto o mitigar.

Redline: matriz de responsabilidades con owner, artefacto, fecha y hito bloqueado. Aviso inmediato, impacto documentado y mitigación razonable. Solo el efecto demostrable sobre el camino crítico mueve fechas.

6. Hosting: ¿quién posee producción y la factura recurrente?

La propuesta dice: «La solución se alojará en el cloud gestionado de la agencia. La infraestructura se repercute mensualmente».

Por qué es una señal de alerta: faltan región, servicios, presupuesto, margen, acceso, backups, monitorización y salida. Si cloud, DNS, dominio, stores o logs viven en cuentas de la agencia, cambiar de proveedor puede requerir reconstruir.

Redline: producción en cuentas del cliente desde el día uno cuando sea posible. Define región, servicios, topes, billing owner, backups, restore probado, monitorización, acceso admin y migración. Infraestructura reproducible como código. Si la agencia aloja temporalmente, fija exportación, plazo de transferencia y migración ensayada.

Regla de precio: añade doce meses realistas de hosting, monitoring y soporte. «Usage based» no significa cero.

7. Licencias de terceros: ¿qué más debes pagar o cumplir?

La propuesta dice: «La agencia podrá usar componentes open source y comerciales estándar para acelerar la entrega».

Por qué es una señal de alerta: open source suele ser correcto, pero las licencias imponen condiciones y los servicios comerciales se renuevan. Debes conocer impacto en distribución, disclosure, seats, transacciones y transferencia.

Redline: exige registro de componentes o SBOM con versión, fuente, licencia y coste recurrente conocido. Los componentes restrictivos o difíciles de sustituir necesitan aprobación. Las licencias comerciales deben ser directas o transferibles. Las cláusulas ICT de la Comisión Europea exigen lista y aprobación cuando la licencia puede limitar distribución o exigir código fuente.

Hard stop: un servicio central licenciado solo a la agencia, sin derecho directo ni reemplazo práctico, es vendor lock-in aunque el custom code se transfiera.

8. Traspaso: ¿puede un equipo competente desplegar la próxima semana?

La propuesta dice: «Al terminar, la agencia entregará el código fuente y documentación razonable».

Por qué es una señal de alerta: una copia del repositorio no es traspaso. Sin historial, CI/CD, infraestructura, credenciales, modelo de datos, runbooks y contexto de issues, el siguiente equipo paga por redescubrir.

Redline: lista repositorio del cliente con historial, pipelines, infraestructura como código, diagramas, esquema y migraciones, tests, runbooks, backup y restore, inventario de cuentas y credenciales, dependencias y licencias, problemas conocidos, decisiones y formación. Un despliegue o restore limpio por el cliente o un sustituto forma parte de la aceptación.

Usa la checklist de traspaso de software como inventario operativo.

9. Terminación: ¿qué recibes si paras en la semana nueve?

La propuesta dice: «Cualquiera puede terminar con 30 días de aviso. Los pagos no son reembolsables y todas las facturas pendientes vencen».

Por qué es una señal de alerta: explica el aviso, no la salida. Falta trabajo parcial, datos, accesos, transición, borrado, licencias y si se paga trabajo no aceptado.

Redline: separa terminación por conveniencia, incumplimiento no subsanado e insolvencia. Define pago de trabajo aceptado, tratamiento del WIP, paquete de artefactos y datos, plazo, rotación de credenciales, evidencia de borrado, licencias continuas y tarifa limitada de transición. Especifica qué obligaciones sobreviven.

Prueba de salida: «Si paramos tras el próximo hito, ¿qué archivos, cuentas, derechos y ayuda llegan en diez días laborables, y qué debemos?». La respuesta debe caber en una tabla.

10. Seguridad: ¿qué controles y evidencias están dentro del alcance?

La propuesta dice: «La agencia sigue best practices del sector para seguridad y protección de datos».

Por qué es una señal de alerta: no existe una única lista, nivel de verificación ni evidencia. No sabrás si threat modelling, access tests, dependency scanning, secrets, notificación de incidentes o pentest están en el precio.

Redline: empieza con clasificación de datos y matriz de responsabilidades. Nombra baseline y versión, por ejemplo nivel o subconjunto de OWASP ASVS, y usa NIST SSDF para responsabilidades de desarrollo seguro. Especifica pruebas, evidencia, remediación, secretos, cifrado, logging, aviso y evaluación independiente. Si se tratan datos personales, el DPA debe cubrir instrucciones, confidencialidad, medidas, asistencia y subencargados bajo el artículo 28 del RGPD.

Aviso de alcance: «pentest ready» no es un pentest. «Cumple RGPD» no es una lista de instrucciones de tratamiento.

11. Subcontratistas: ¿quién construye y quién ve los datos?

La propuesta dice: «La agencia podrá contratar especialistas cualificados y seguirá siendo responsable».

Por qué es una señal de alerta: no conoces trabajo, ubicación, acceso, flow-down de obligaciones ni si la agencia tiene derechos suficientes sobre el output para transferirlo.

Redline: revela subcontratistas materiales, rol, ubicación y acceso. Exige aviso y objeción o aprobación cuando el riesgo lo justifique. Traslada confidencialidad, seguridad, datos, auditoría e IP. Mantén a la agencia responsable. El artículo 28 del RGPD exige autorización previa específica o general para otro encargado.

Distinción: un especialista nombrado pronto para un problema conocido es buena señal. Un bench invisible que sustituye a los seniors que vendieron el proyecto es riesgo de entrega.

12. Definición de terminado: ¿qué calidad está incluida?

La propuesta dice: «Una feature está completa cuando está sustancialmente implementada y demostrada al cliente».

Por qué es una señal de alerta: una demo prueba el happy path una vez. No demuestra review, tests, accesibilidad, seguridad, documentación, deployment, observabilidad o limpieza. Ese trabajo reaparece como hardening fuera del precio.

Redline: terminado significa code reviewed y merged; tests acordados en verde; aceptación cumplida; security checks limpios; accesibilidad y navegadores comprobados cuando corresponda; documentación actualizada; desplegado en el entorno nombrado; monitorización y errores activos; sin blockers abiertos. Versiona la definición y nombra quién puede cambiarla.

La Scrum Guide vincula Definition of Done al Increment como compromiso de calidad. La idea sirve sin Scrum: «terminado» describe el estado de la obra, no la confianza durante una demo.

"El precio de una propuesta de software no es una cifra. Es el fee principal más cada ambigüedad que el comprador tendrá que financiar después. Las buenas cláusulas no vuelven adversarial la relación; evitan que la incertidumbre normal se convierta en negociación bajo presión."

Aceptación, definición de terminado y traspaso no son lo mismo

Combinar los tres en «firma del cliente» cuesta caro. Una feature puede pasar el test de negocio con código inmantenible. Un codebase limpio puede existir mientras el cliente no sabe desplegar. Comprueba los tres estados por separado.

Cómo comparar el precio real de dos propuestas

Precio comparable = build + trabajo obligatorio excluido + recurrente del primer año + trabajo del cliente valorado + salida esperada.

Son cifras inventadas, no benchmarks de Wavect. El método es lo importante: una oferta menor puede costar más si deja fuera trabajo obligatorio. Pide a cada agencia la misma matriz de inclusiones.

Cómo puntuar: 0, 1 o 2 por cláusula

• 0 - ausente. No trata la cláusula o falta un anexo referenciado.
• 1 - subjetiva. Existe, pero usa «razonable», «estándar» o «a tiempo» sin owner, prueba o consecuencia.
• 2 - operativa. Nombra owner, artefacto o prueba, plazo, dependencias y resultado si no se cumple.

Detente con cualquier puntuación si la cadena de IP es dudosa, los datos personales carecen de términos operables, hosting o licencias no se transfieren, o la terminación te deja sin código y datos.

Qué hacer después del análisis

1. Enviar un redline consolidado, no doce hilos separados.
2. Revisar exclusiones e hipótesis con quien dirigirá la entrega.
3. Actualizar SoW y anexos. Las notas de reunión no son el contrato.
4. Validar viabilidad, dependencias, seguridad y traspaso con un perfil técnico senior.
5. Adaptar el lenguaje legal con abogado cualificado para jurisdicción y riesgo.

Una buena agencia debería agradecer la mayoría de estas preguntas. Los límites precisos protegen su margen y tu presupuesto. Resistirse a todo detalle es la señal; debatir una asignación concreta con razones es negociación normal.

Fuentes y lecturas adicionales

1. UK Cabinet Office (2025), Model Services Contract guidance, versión 2.2. Aceptación, pruebas, propiedad intelectual, cambios y salida. gov.uk (consultado el 13 de julio de 2026).
2. Comisión Europea (2021), Additional IP clauses for ICT contracts. Código, documentación, open source y registro de componentes. commission.europa.eu (consultado el 13 de julio de 2026).
3. European IP Helpdesk, Frequently asked questions on IP assignment and licences. Alcance de cesión, garantías, indemnización y sublicencias. intellectual-property-helpdesk.ec.europa.eu (consultado el 13 de julio de 2026).
4. Comisión Europea, Can someone else process data on my organisation's behalf? Encargados, subencargados y contenido mínimo del artículo 28 del RGPD. commission.europa.eu (consultado el 13 de julio de 2026).
5. NIST (2022), Secure Software Development Framework, SP 800-218 v1.1. Vocabulario para requisitos de seguridad y adquisición. csrc.nist.gov (consultado el 13 de julio de 2026).
6. OWASP, Application Security Verification Standard v5.0.0. Baseline verificable para compras y contratos. owasp.org (consultado el 13 de julio de 2026).
7. OWASP, Secure Software Contract Annex. Preguntas sobre requisitos, verificación, reporting y despliegue seguro. owasp.org (consultado el 13 de julio de 2026).
8. WIPO GREEN (2016), Licensing Checklist. SoW, entregables, especificaciones, pruebas, aceptación e IP. wipo.int (consultado el 13 de julio de 2026).
9. Schwaber, K. y Sutherland, J. (2020), The Scrum Guide. Definition of Done como compromiso de calidad del Increment. scrumguides.org (consultado el 13 de julio de 2026).