Cuando un software no sirve, la frustración puede hacer que todo parezca evidencia. Pero para demostrar incumplimiento necesitas más que una mala experiencia o un manual que describe lo que debía hacer.
Debes comparar lo contratado con lo entregado y probar el funcionamiento en escenarios documentados.
Define qué significa “no sirve”
Puede significar cosas distintas:
Un software puede fallar porque no instala o compila, porque no permite completar procesos, produce errores, entrega resultados incorrectos u omite funciones contratadas. También puede depender de piezas que el proveedor no entregó o mostrar datos fijos que aparentan operación. Cada posibilidad exige una prueba distinta, no una afirmación general de que el sistema es malo.
Convierte esas observaciones en casos reproducibles: versión, datos, usuario, pasos, resultado esperado y resultado real. Un error de cálculo necesita verificar fórmula y datos; una instalación fallida necesita ambiente y dependencias; una supuesta operación fija necesita comprobar si cambia realmente la información.
En un caso real de software inservible, el proveedor mostraba pantallas con datos que parecían acreditar funcionamiento. Al ejecutar procesos completos se comprobó que esa apariencia no bastaba: determinadas operaciones esenciales no resistían un ejercicio de principio a fin. Los datos fijos ayudaban a sostener una demostración, pero no demostraban que el sistema resolviera el proceso contratado.
La revisión técnica separó estética, estructura y operación. Se probaron entradas, salidas, persistencia y errores con condiciones documentadas. También se reconocieron las partes que sí funcionaban, porque una lista de defectos no necesita negar lo evidente para ser sólida. El contrato y los requisitos permitieron después decidir qué diferencias eran realmente incumplimientos.
Si compraste un sistema que no sirve, conserva instaladores, código, bases y comunicaciones antes de aceptar otra reparación. Realiza pruebas en un ambiente controlado, no en la operación viva de tu empresa. El abogado vincula defectos con entregables y pagos; el peritaje reproduce causa y alcance sin convertir preferencias personales en errores. La evidencia fuerte no es decir “es basura”, sino mostrar exactamente qué proceso no puede completarse y por qué.
El cliente debe preservar el código y las versiones antes de aceptar reparaciones, sin ejecutar pruebas destructivas en producción. El abogado debe vincular defectos y efectos con el contrato, mientras el peritaje determina causa y alcance. Reconocer lo que sí funciona no debilita la reclamación: la hace más precisa y difícil de descartar como simple inconformidad.
Cada hipótesis necesita pruebas distintas. No la resumas como “está mal hecho”.
El manual no demuestra el sistema
Un manual impreso describe cómo debería operar. No contiene código, base de datos, registros ni metadatos suficientes para evaluar el software.
La revisión puede requerir:
- Código fuente o sistema funcionando.
- Versión y compilación.
- Entorno de ejecución.
- Base de datos.
- Registros de errores.
- Archivos originales y hashes.
- Contrato y anexos técnicos.
Un folleto puede explicar el producto; no demuestra que cumpla.
Diseña pruebas reproducibles
Documenta cada escenario con:
- Requisito evaluado.
- Datos de entrada.
- Pasos ejecutados.
- Resultado esperado.
- Resultado obtenido.
- Error exacto.
- Evidencia de archivos y registros.
Si una tarea falla de forma repetida en módulos distintos, puede existir un patrón de plataforma. Si falla solo con datos del cliente, puede ser configuración o uso.
Responsabilidad técnica
Determina si el error pertenece al proveedor, al desarrollo propio, a la plataforma base o al entorno.
Si la plataforma tiene errores de núcleo que el cliente no puede modificar por derechos de autor, la responsabilidad cambia. No es lo mismo corregir un módulo propio que reparar el motor que el proveedor entregó.
Preserva antes de actualizar
No reinstales ni actualices todo antes de conservar versiones y registros. Una actualización puede ocultar el defecto o cambiar el entorno que necesitas probar.
Guarda también contrato, adendas, propuesta, actas y comunicaciones. La obligación debe compararse con lo prometido, no con una versión ideal del producto.
La falla debe repetirse en condiciones conocidas
Una reclamación por software defectuoso o aplicación inservible necesita pruebas con versión, datos, usuario y entorno documentados. Si el error no se reproduce, pueden existir condiciones específicas que deben investigarse, no inventarse. El cliente necesita continuidad y copias; el abogado necesita relacionar cada defecto con el contrato y sus efectos. El peritaje distingue programación, infraestructura y terceros, sin publicar vulnerabilidades ni realizar pruebas destructivas en producción.
Convierte cada queja en una prueba repetible
Describe un proceso completo con datos de entrada, usuario, versión y ambiente. Explica qué debería ocurrir según el contrato y qué ocurrió realmente. Adjunta registros, videos y capturas como fuentes complementarias, no como sustitutos de un procedimiento que otra persona pueda repetir.
Clasifica los problemas: impedimento para operar, pérdida de datos, error de cálculo, falla de seguridad, demora o diferencia estética. No todos tienen el mismo efecto ni demuestran por sí solos que todo el sistema carece de utilidad. La clasificación permite evaluar gravedad sin exagerar.
Conserva la versión analizada antes de aceptar parches. Si el proveedor modifica el sistema durante la disputa, registra fecha, cambios y resultado. Una reparación posterior no prueba que siempre funcionó, pero tampoco debe usarse para impedir que el cliente reciba un servicio mejor.
Revisa integraciones y obligaciones de terceros. Una pasarela de pago, una licencia o un servidor puede ser la causa del fallo. La responsabilidad debe asignarse con registros y contratos, no por quién entregó la pantalla donde finalmente apareció el error.
El peritaje debe reconocer lo que sí funciona y las pruebas que no pueden reproducirse. Esa imparcialidad evita que el informe parezca escrito para ganar una discusión. La conclusión técnica puede respaldar incumplimientos sin decidir por sí sola rescisión, daños o cantidades, que requieren análisis jurídico y financiero adicional.
