Cuando una agencia cobra por una App y entrega algo que no funciona, llamarlo “código basura” describe la frustración, pero no demuestra el incumplimiento.
Necesitas pruebas de funcionamiento, contrato, arquitectura y errores reproducibles. El objetivo es mostrar qué prometió y qué entregó realmente.
Revisa lo contratado antes del código
Reúne propuesta, contrato, anexos, entregables, módulos, matrices, aceptación y aclaraciones de responsabilidad.
Una promesa de producto terminado ayuda a comparar lo que debía incluir con lo que efectivamente existe.
Documenta errores con precisión
Registra:
Documenta versión y compilación, entorno, datos de entrada, pasos ejecutados, errores y advertencias, procesos incompletos y resultados esperados y obtenidos. Esa metodología permite distinguir entre código que simplemente no te gusta y una aplicación que no cumple funciones contratadas.
Revisa también si faltan dependencias, documentación o componentes necesarios para compilar y mantener. Un inicio de sesión puede funcionar mientras el proceso esencial de compra, registro o reporte falla. El análisis debe reconocer lo que sí opera y explicar qué no pudo evaluarse por falta de acceso.
En un peritaje real de una aplicación, el problema no se resolvió opinando que el código era feo. Se revisó si podía compilarse, si los procesos contratados funcionaban y qué componentes estaban realmente integrados. Las pantallas con datos de demostración no acreditaban por sí solas que el sistema completara operaciones nuevas. La evaluación técnica convirtió la inconformidad en hallazgos reproducibles.
También se identificaron funciones que sí operaban y causas que no pertenecían al código principal. Esa separación permitió evitar una conclusión exagerada y concentrarse en los defectos que impedían el uso contratado. Versiones, instaladores y registros ayudaron a comprobar qué se entregó antes de cualquier reparación.
Si una agencia te entregó algo inservible, conserva repositorios, commits, bases y comunicaciones, y no publiques el código para pedir opiniones: puede contener secretos o datos personales. El abogado relaciona defectos con alcance, pagos y aceptación; el peritaje prueba procesos en un ambiente controlado. “Código basura” es una descarga de frustración; una pericial útil explica qué proceso falla, por qué y qué efecto tiene.
Miles de errores no se suman como argumento emocional: deben clasificarse por origen y efecto en la operación.
Prueba un ejercicio completo
Una pantalla de inicio puede ocultar que el sistema no realiza procesos centrales. Ejecuta un ciclo completo con los módulos contratados:
- Registro.
- Consulta.
- Operación.
- Validación.
- Reporte.
- Relación entre módulos.
- Generación de libros o resultados requeridos.
Si los reportes contienen datos fijos en lugar de información de base de datos, documéntalo. Una demostración maquillada no es funcionamiento.
Distingue núcleo y desarrollo propio
Si el error pertenece a la plataforma entregada por la agencia, revisa si tu equipo puede corregirlo. Si está protegido y no puedes modificarlo, la dependencia técnica también es relevante.
No asumas que tu equipo es responsable por no poder arreglar un núcleo que el proveedor no permite tocar.
Preserva evidencia antes de actualizar
Conserva código, errores, registros, contrato y entorno. No reinstales ni actualices antes de documentar la versión fallida.
Una revisión independiente puede convertir la frustración en un dictamen técnico verificable.
El código se evalúa por entregables y funcionamiento
Una app inservible o desarrollo de software incumplido no se demuestra por estilo de código ni porque otra persona lo haría distinto. Hay que revisar si compila, qué funciones completa, qué dependencias faltan y qué criterios de aceptación existían. El cliente necesita preservar repositorios y paquetes; el abogado necesita vincular defectos con alcance y pagos. El análisis no publica credenciales ni vulnerabilidades, y distingue errores críticos de mejoras no contratadas.
Evalúa entregables, no únicamente estilo de programación
Un código distinto a tus preferencias no es automáticamente inservible. Define requisitos, funciones, plataformas, rendimiento y criterios de aceptación. Compara esos puntos con el repositorio, los instaladores y las versiones publicadas antes de llamar basura al trabajo.
Conserva la historia de commits, paquetes entregados, credenciales administrativas, documentación y comunicaciones. Calcula huellas y registra qué copia analizas. Si la agencia actualiza después, documenta la nueva versión sin perder la original.
Prepara pruebas funcionales con datos controlados: registro, acceso, compra, notificación, sincronización o lo que la app promete. Registra pasos, resultado esperado, resultado observado y logs. Una pantalla de error puede ser el síntoma; la causa debe buscarse en código, servidor, dependencias y configuración.
Revisa si faltan componentes necesarios para compilar o mantener el producto. También identifica bibliotecas de terceros, licencias y credenciales expuestas. No publiques el código para pedir opiniones: puedes revelar secretos y debilitar tu posición.
El dictamen debe señalar qué funciona, qué falla y qué no pudo probarse por falta de acceso. Distingue defectos críticos, mejoras y nuevas funciones no contratadas. Esa clasificación permite discutir incumplimiento con hechos y evita que la agencia responda a todo con la frase en mi computadora sí funciona sin ofrecer el ambiente ni la evidencia de esa afirmación.
