
Peritación de páginas web y proyectos de software
Comprobamos si el proveedor realizó el trabajo contratado, qué porcentaje está realmente terminado, si las funciones cumplen los requisitos y qué causas técnicas explican retrasos, defectos o el fracaso del proyecto. Elaboramos informes para reclamaciones, negociación, mediación y procedimientos judiciales.
Cumplimiento contractualPorcentaje de ejecuciónCalidad y defectosCausalidad técnica
¿Qué estudia una peritación de páginas web, CMS, ERP o software?
Compara el contrato, la oferta, los requisitos y los entregables pactados con el sistema realmente desarrollado. El perito identifica funciones completas, parciales, defectuosas o ausentes; analiza documentación, código, repositorios, pruebas, despliegues y comunicaciones; calcula un grado de ejecución razonado y explica qué incidencias dependen del proveedor, del cliente, de terceros o de decisiones compartidas.
Proyectos tecnológicos que podemos peritar
La peritación de páginas web no se limita a observar su diseño. Un proyecto moderno puede incluir aplicaciones, bases de datos, integraciones, infraestructura, licencias, analítica, seguridad y procesos de negocio. El alcance se adapta a lo contratado.
🌐
Páginas web y portales
Web corporativa, portal de clientes, intranet, área privada, buscador, formularios, contenidos, accesibilidad y rendimiento.
🧱
CMS
WordPress, Drupal, Joomla y gestores propios: plantillas, plugins, roles, flujos editoriales, actualizaciones y personalizaciones.
🛒
Comercio electrónico
WooCommerce, PrestaShop, Magento y soluciones a medida: catálogo, pagos, impuestos, stock, pedidos y transportistas.
🏭
ERP y CRM
Odoo, SAP, Microsoft Dynamics y otros sistemas: módulos, migración, procesos, permisos, informes e integraciones.
⌨️
Programación a medida
Aplicaciones web, SaaS, APIs, back-office, automatizaciones y plataformas creadas para requisitos específicos.
☁️
Infraestructura y DevOps
Hosting, nube, dominios, copias, despliegues, repositorios, entornos, monitorización, seguridad y continuidad.
También podemos examinar aplicaciones móviles vinculadas, pasarelas de pago, servicios de terceros, importaciones de datos, conectores con contabilidad, marketplaces o sistemas logísticos. La pregunta no es únicamente si “se ve una web”, sino si el conjunto contratado presta el servicio acordado.
Incumplimientos habituales en contratos informáticos
En muchos conflictos, cliente y proveedor describen realidades distintas. El proveedor afirma que el proyecto está terminado y pendiente de aceptación; el cliente sostiene que no puede utilizarlo. El informe pericial convierte esas afirmaciones en elementos verificables.
📋
Funcionalidades no entregadas
Módulos, pantallas, informes, automatizaciones o integraciones incluidos en el alcance no existen o solo están simulados.
🐞
Errores que impiden operar
La función existe, pero produce resultados incorrectos, pierde datos, falla con casos reales o no soporta el volumen previsto.
🔄
Migración incompleta
Faltan registros, históricos, documentos o relaciones; hay duplicados, formatos incorrectos o ausencia de reconciliación.
🔌
Integraciones defectuosas
ERP, CRM, banco, firma, correo, logística o API no intercambian la información acordada o dependen de procesos manuales.
🔐
Seguridad insuficiente
Permisos, copias, cifrado, actualizaciones o tratamiento de secretos no responden al contrato ni a las necesidades del sistema.
📚
Sin documentación ni entrega
No se facilitan código, repositorio, credenciales, manuales, licencias, despliegue o conocimiento necesario para continuar.
También pueden existir cambios de alcance, peticiones adicionales, falta de datos por parte del cliente, retrasos en decisiones, dependencia de un proveedor externo o requisitos que nunca se definieron. La peritación debe incorporar estas circunstancias y no asumir que todo retraso es automáticamente imputable a quien programa.
Qué se compara para determinar el cumplimiento
| Base de comparación | Qué aporta | Precaución |
|---|---|---|
| Contrato y anexos | Objeto, alcance, hitos, precio, aceptación, mantenimiento, propiedad y obligaciones. | Puede usar términos genéricos o remitir a documentos externos. |
| Oferta y propuesta técnica | Funcionalidades, arquitectura, equipo, calendario y compromisos previos. | Hay que comprobar si quedó incorporada al acuerdo. |
| Requisitos e historias de usuario | Comportamiento esperado, reglas, prioridades y criterios de aceptación. | Pueden haber cambiado durante el proyecto. |
| Actas, correos y tickets | Decisiones, incidencias, bloqueos, solicitudes y conocimiento de las partes. | Deben ordenarse cronológicamente y en contexto. |
| Repositorio y entregas | Código, versiones, autores técnicos, ramas, etiquetas y evolución. | Un commit no equivale automáticamente a funcionalidad terminada. |
| Sistema desplegado | Qué funciona en el entorno de pruebas o producción. | Debe identificarse versión, configuración y dependencias. |
| Pruebas y aceptación | Resultados esperados y reales, defectos, cobertura y validación. | La ausencia de pruebas no demuestra por sí sola que todo falle. |
El contrato es la referencia jurídica, pero el perito traduce expresiones como “ERP operativo”, “integración completa”, “diseño responsive” o “entrega del código” a comprobaciones técnicas. Cuando un requisito es ambiguo, debe indicarse y analizarse cómo lo entendieron las partes durante la ejecución.
Cómo calculamos el porcentaje de realización de un proyecto
No existe un porcentaje fiable basado únicamente en horas facturadas, pantallas dibujadas o líneas de código. Se construye una matriz de entregables ponderados según su importancia contractual y funcional. Cada elemento se clasifica con criterios reproducibles: no iniciado, iniciado, parcialmente funcional, completado con defectos o aceptado.
Ejemplo visual de una matriz de avance
Requisitos y diseño
100%
Funciones principales
70%
Integraciones
40%
Migración de datos
25%
Pruebas y correcciones
20%
Documentación y entrega
10%
El ejemplo no es una plantilla universal. En un comercio electrónico, pagos y pedidos pueden pesar más que el diseño; en un ERP, la migración y los procesos contables pueden ser críticos; en un SaaS, seguridad, aislamiento de clientes y facturación pueden condicionar la utilidad completa.
Terminado no significa necesariamente aceptable
Una funcionalidad puede estar programada pero no cumplir el criterio pactado, fallar en producción o carecer de pruebas. Por eso distinguimos existencia, terminación técnica, calidad, integración, documentación y aceptación. Un módulo que abre una pantalla pero no guarda correctamente los datos no debería computar como cien por cien terminado.
Valor económico y valor funcional
El porcentaje técnico no equivale automáticamente al porcentaje del precio exigible ni al daño reclamable. Puede haber componentes costosos que no son visibles y funciones pequeñas que resultan esenciales para operar. El perito documenta la realidad técnica; la valoración contractual y económica se coordina con la dirección letrada y, cuando procede, con especialistas contables.
Por qué no se cumplió y quién contribuyó al problema
El informe reconstruye la cronología y relaciona cada incidencia con sus dependencias. En vez de afirmar de forma genérica que “la culpa es del programador” o “el cliente no colaboró”, identifica hechos concretos y su impacto técnico.
Para cada causa se estudia si estaba prevista, cuándo se comunicó, quién podía resolverla, qué acciones se adoptaron y qué efecto tuvo sobre hitos posteriores. Una dependencia del cliente puede explicar un retraso concreto, pero no necesariamente todos los defectos. Del mismo modo, un cambio de alcance no justifica que fallen funciones previamente pactadas.
Documentación y evidencias que conviene conservar
Cuanto antes se preserve el estado del proyecto, más fácil será distinguir la versión entregada de cambios posteriores. No borres repositorios, tickets ni entornos aunque el proveedor ya no continúe.
Contrato y alcance
Contrato, anexos, oferta, presupuesto, pliego, requisitos, diseños, cronograma, hitos, facturas y criterios de aceptación.
Comunicaciones
Correos, actas, chats, tickets, incidencias, solicitudes de cambio, avisos de bloqueo y respuestas de cada parte.
Código y versiones
Repositorios Git, exportaciones, paquetes entregados, etiquetas, ramas, historial, dependencias y archivos de configuración no secretos.
Entornos y datos
Accesos autorizados a pruebas y producción, copias, bases de datos, logs, inventario de servidores, dominios y servicios.
Pruebas y aceptación
Planes de prueba, resultados, vídeos, capturas, UAT, defectos, incidencias cerradas y actas de entrega o rechazo.
Licencias y titularidad
Plugins, plantillas, software de terceros, cuentas, dominios, derechos sobre el código, documentación y condiciones de uso.
Si la relación está deteriorada, conviene asesorarse antes de revocar accesos o modificar el sistema. La contención de un riesgo de seguridad puede ser urgente, pero debe documentarse. Una copia forense o exportación verificable puede conservar el estado de la web, el servidor o el repositorio en una fecha concreta.
Cómo realizamos la peritación del proyecto informático
Definición de las preguntas
Concretamos qué debe determinar el informe: cumplimiento, porcentaje, defectos, causas, aprovechamiento, valoración técnica o revisión de una pericial anterior.
Inventario y preservación
Registramos contrato, versiones, repositorios, sistemas, bases de datos, comunicaciones y documentación. Se identifica qué estaba disponible y en qué fecha.
Conversión del alcance en criterios
Transformamos obligaciones y requisitos en entregables verificables, con pesos y criterios de aceptación razonados.
Pruebas funcionales y técnicas
Ejecutamos casos relevantes, revisamos integraciones, datos, permisos, rendimiento, seguridad, documentación y compatibilidad según el objeto.
Análisis de código y trazabilidad
Cuando está disponible y es pertinente, se revisan arquitectura, historial, dependencias, calidad, pruebas y relación con las entregas. No se analiza más información de la necesaria.
Cronología y causalidad
Relacionamos requisitos, cambios, bloqueos, entregas y defectos para explicar qué provocó cada desviación y qué parte podía actuar.
Informe, anexos y ratificación
Presentamos metodología, matriz de cumplimiento, resultados, limitaciones y conclusiones. Si es necesario, ratificamos ante el órgano judicial.
Ejemplos de peritación por tipo de proyecto
🛍️
Tienda online que no puede vender
Existe catálogo y diseño, pero fallan pagos, impuestos, stock o correos. Se mide qué entregables son operativos y qué defectos impiden la finalidad comercial.
📊
ERP implantado parcialmente
Se revisan módulos, migración, saldos, roles, informes, integraciones y procesos. Una demo no equivale a una implantación productiva.
🧑💻
Aplicación a medida abandonada
Se determina el estado del código, documentación, cobertura funcional, dependencias y coste técnico aproximado para continuar o rehacer.
🧱
WordPress con desarrollo defectuoso
Se separan problemas del núcleo, plantilla, plugins, personalización, hosting, mantenimiento y uso posterior del cliente.
Certificación, plagio, ataques y valoración de páginas web
Además de conflictos de desarrollo, mantenemos los servicios tradicionales de peritación de páginas web. Podemos preservar contenido publicado, comparar plagios, analizar incidentes de seguridad y estudiar el valor técnico de una plataforma.
Certificación de contenido
Documentación de URL, fecha, textos, imágenes, precios, condiciones, formularios, código visible y otros elementos relevantes.
Plagio y copia
Comparación estructurada de textos, imágenes, catálogos, diseño, recursos, código accesible y fechas disponibles.
Ataques y manipulación
Análisis de logs, accesos, malware, cambios no autorizados, caída, redirecciones y afectación a datos.
Valoración técnica
Arquitectura, desarrollo, activos, licencias, deuda técnica, mantenimiento, documentación y capacidad de evolución.
Contenido eliminado
Estudio de copias, archivos históricos, correos, cachés, registros y otras fuentes, indicando su origen y límites.
Contrapericial
Revisión crítica de informes sobre software, webs, código o incidentes aportados por otra parte.
Si ya existe un informe contrario, consulta nuestro servicio de informe contrapericial informático. Para acreditar una web en un momento concreto también puede coordinarse una preservación temprana antes de que cambie el contenido o el sistema.
Vídeo: el informe del perito informático en cuatro pasos
Este vídeo del canal de GlobátiKa Peritos Informáticos resume cómo se transforma un problema tecnológico en un informe técnico estructurado, comprensible y útil para el procedimiento.
Consulta más explicaciones en el canal de YouTube de GlobátiKa Peritos Informáticos.
Información útil para abogados y empresas
Preguntas periciales que pueden plantearse
- ¿Qué entregables estaban definidos y cuáles se encuentran completos, parciales, defectuosos o ausentes?
- ¿Qué porcentaje de ejecución resulta técnicamente justificable y con qué ponderación?
- ¿El sistema cumple los requisitos funcionales, de integración, seguridad y documentación pactados?
- ¿Los defectos impiden el uso previsto o pueden corregirse de forma proporcionada?
- ¿Qué parte del trabajo entregado es reutilizable y qué parte requiere rehacerse?
- ¿Qué hechos técnicos explican cada retraso y qué dependencias intervinieron?
- ¿Se entregaron código, datos, credenciales, documentación y licencias necesarias?
- ¿Las afirmaciones de avance, aceptación o imposibilidad técnica son coherentes con la evidencia?
La Ley de Enjuiciamiento Civil permite aportar dictámenes cuando se necesitan conocimientos técnicos para valorar hechos relevantes. El Código Civil establece que las obligaciones contractuales deben cumplirse conforme a lo pactado. La aplicación jurídica concreta, los remedios, daños y resolución deben ser valorados por la dirección letrada.
Plazo y precio de la peritación
Dependen del volumen contractual, número de módulos, repositorios, entornos, integraciones, datos, periodo del proyecto, pruebas necesarias, acceso a sistemas, urgencia y ratificación. Una web corporativa no requiere el mismo trabajo que un ERP implantado durante dos años. Tras una revisión inicial proponemos un alcance que responda a las preguntas importantes sin convertir la peritación en una auditoría ilimitada.
Preguntas frecuentes sobre peritación de páginas web y software
Las respuestas están abiertas para facilitar la lectura, la accesibilidad y la consulta directa por buscadores y asistentes de inteligencia artificial.
¿Se puede saber qué porcentaje del proyecto está terminado?
Sí, si pueden definirse entregables y criterios verificables. Se ponderan por importancia y se clasifica su estado. El porcentaje debe explicar su método y limitaciones.
¿Las horas facturadas demuestran el avance?
No necesariamente. Las horas pueden acreditar actividad, pero el cumplimiento se comprueba sobre entregables, resultados y obligaciones. Muchas horas no convierten una función defectuosa en terminada.
¿Puede peritarse un contrato que apenas tiene requisitos?
Sí, aunque la ambigüedad limitará algunas conclusiones. Se estudian oferta, comunicaciones, demos, tickets, conducta posterior y finalidad conocida, diferenciando lo pactado de las expectativas no documentadas.
¿Se puede determinar quién tiene la culpa?
El perito identifica causas técnicas y contribuciones de proveedor, cliente y terceros. La responsabilidad jurídica definitiva corresponde al tribunal y exige interpretar contrato, prueba y normativa.
¿Necesitáis acceder al código fuente?
No siempre, pero puede ser esencial para valorar avance, calidad, historial o posibilidad de continuar. Otras cuestiones pueden resolverse con el sistema, documentación, logs y pruebas.
¿Qué pasa si el proveedor no entrega el repositorio?
Se documenta qué estaba obligado a entregar, qué materiales existen y qué efecto tiene la ausencia sobre mantenimiento y continuidad. El abogado valorará las medidas para obtenerlo.
¿Una funcionalidad con errores cuenta como terminada?
Depende de la gravedad y del criterio de aceptación. Puede considerarse parcial, completada con defectos o no aceptable si impide su finalidad. El informe debe justificar la clasificación.
¿Puede analizarse un ERP como Odoo, SAP o Dynamics?
Sí. Se revisan módulos contratados, parametrización, desarrollos, migración, permisos, procesos, informes, integraciones, documentación y funcionamiento en el entorno acordado.
¿Peritáis WordPress y WooCommerce?
Sí. Se distinguen núcleo, plantilla, plugins, desarrollos propios, hosting y mantenimiento para localizar el origen de defectos, incompatibilidades o problemas de seguridad.
¿Se puede valorar lo que cuesta terminar el proyecto?
Puede estimarse el esfuerzo técnico con hipótesis y alcance definidos. No debe confundirse con una oferta cerrada ni con la valoración jurídica completa de daños.
¿Puede saberse si conviene continuar o rehacer?
Se analiza reutilización del código, arquitectura, deuda técnica, documentación, pruebas, dependencias y riesgos. La decisión empresarial también depende de coste, plazos y estrategia.
¿Sirven los correos y tickets como evidencia?
Sí, ayudan a reconstruir requisitos, cambios, bloqueos y aceptación. Deben conservarse completos y relacionarse con versiones y hechos técnicos, no interpretarse de forma aislada.
¿Puede certificarse el estado actual antes de cambiar de proveedor?
Sí. Es recomendable preservar versiones, repositorios, bases, configuración, logs, capturas y accesos antes de migrar o modificar el sistema.
¿El informe puede usarse en juicio?
Se redacta para explicar metodología, hallazgos, limitaciones y conclusiones, con posibilidad de ratificación. La valoración final corresponde al órgano judicial.
¿Hacéis contrapericiales de informes sobre software?
Sí. Revisamos alcance, evidencias, pruebas, porcentajes, criterios, causalidad y si las conclusiones están realmente respaldadas.
¿Qué debo enviar para solicitar presupuesto?
Contrato, oferta, descripción del proyecto, fechas, importe, situación actual, documentación disponible, sistemas implicados y preguntas que necesita responder el abogado.
Fuentes públicas y referencias
Esta guía se apoya en el Código Civil consolidado, la Ley de Enjuiciamiento Civil, los requisitos de conformidad de contenidos y servicios digitales del texto refundido de la Ley General para la Defensa de los Consumidores y Usuarios, la regulación de programas de ordenador en la Ley de Propiedad Intelectual y las prácticas de desarrollo seguro del NIST Secure Software Development Framework. Son fuentes públicas, no páginas de competidores. La aplicación jurídica depende del contrato y del caso.
Contenido revisado en julio de 2026.
¿Tu proyecto web, CMS o ERP no se ha entregado como se contrató?
Cuéntanos qué se pactó, qué se ha pagado, qué funciona, qué falta y cuál es la fecha límite. Te indicaremos qué documentación preservar y qué preguntas puede responder una peritación proporcionada.

