Incumplimiento del contrato de desarrollo de software: ¿qué puedo hacer?

¿Tienes razón?

En los conflictos de desarrollo de software, la fortaleza de su caso se mide por cuatro elementos:

1) El contrato y sus anexos. El contrato debe contener el alcance, entregables, criterios de aceptación, propiedad intelectual y forma de pago. Si el contrato está claro y el desarrollador no cumple, su posición es sólida. Si el contrato es verbal o ambiguo, la disputa depende de pruebas complementarias.

2) Requisitos y criterios de aceptación. ¿Existen especificaciones funcionales, tickets de incidencias o actas de aceptación? Si firmaron criterios de aceptación y el software no pasa esos criterios, usted tiene base para reclamar.

3) Prueba técnica. Registros de versiones, repositorios con tags, logs de despliegue y capturas de errores documentan el estado del desarrollo. Si tiene evidencias técnicas temporales—por ejemplo, un demo fallido—son útiles.

4) Comunicaciones y oportunidades de reparación. Si usted dio instrucciones, facilitó información y el proveedor no respondió o no corrigió, ello refuerza su reclamación. Si hubo intentos de remediación, esas gestiones suelen pesar a favor del desarrollador.

Si el contrato y las pruebas documentales le respaldan, su posición es fuerte; sin documentación la disputa será más difícil y dependerá de pruebas técnicas y testigos.

Cómo se soluciona

1. Documente el incumplimiento ahora mismo. Exporte correos, tickets, versiones de repositorios y capturas de pantalla de errores. Si el sistema está accesible, haga copias y registra logs de funcionamiento y de fallos. Esto es algo que puede hacer sin abogado.

1. Envíe una reclamación fehaciente por escrito. Describa los incumplimientos concretos, los criterios de aceptación afectados y solicite la corrección o la entrega. Indique las pruebas que aporta y los plazos para subsanar (sin poner números) y guarde constancia de la notificación.

1. Intente un arreglo técnico. Proponga un plan de pruebas conjunto, con criterios de aceptación y entregas parciales. Muchas veces se resuelve mediante tres o cuatro iteraciones de corrección.

1. Considere la mediación o conciliación. Antes de litigar, la negociación asistida por un tercero neutral permite a menudo alcanzar un acuerdo eficaz: correcciones, abonos parciales o rescisión con compensación.

1. Valore la rescisión y la reclamación de daños. Si el proveedor no corrige, puede reclamar cumplimiento forzoso, la rescisión del contrato y la reparación por daños y perjuicios. Para estimar daños y preparar la demanda necesitará un abogado y, con frecuencia, un perito técnico que cuantifique el defecto y el coste de arreglo.

1. Proteja la propiedad intelectual y los datos. Si teme que el proveedor se quede con el código o utilice su información, cambie accesos, recupere backups y documente las copias de repositorio. Si hay riesgo de uso indebido, actúe legalmente para impedirlo.

Qué puede pasar

1) Se arregla con una corrección y entrega. Lo más común: el proveedor hace ajustes y se firma un acta de conformidad. Un acuerdo de rectificación puede incluir compensaciones económicas por el retraso o por las fallas.

2) Acuerdo con compensación. Ambas partes pactan rescisión parcial o total con compensación económica y, posiblemente, la entrega de código fuente y documentación. Un acuerdo puede ser mejor que un litigio largo y costoso.

3) Juicio o procedimiento civil. Si no hay acuerdo, puede acudir a la vía judicial para reclamar cumplimiento o daños. En juicio se valorarán las pruebas técnicas y la pericia, y si pierde la parte demandada puede ser condenada a entregar, reparar y pagar daños. En la práctica, la ejecución y cobro dependen de la solvencia del proveedor.

Y si gana, ¿cobro? Ganar la sentencia es solo un paso; cobrar depende del patrimonio del proveedor. Por eso muchos compradores negocian retenciones de precio o garantías desde el inicio.

Errores que arruinan el caso

• No conservar versiones y tickets: sin historial técnico prueban poco.
• Aceptar entregas verbales sin actas firmadas de aceptación.
• Entregar pagos finales sin firmar acta de recepción ni comprobar criterios.
• Cambiar claves de acceso sin documentar y sin avisar si luego quiere reclamar la entrega: puede interpretarse como obstrucción.
• Emprender medidas técnicas drásticas (borrar repositorios, cerrar cuentas) que impidan la prueba de lo sucedido.