Peritación de páginas web, CMS, ERP y software a medida
El análisis pericial compara lo contratado, lo desarrollado, lo entregado y lo que funciona realmente en el entorno acordado.
CMS · ERP · E-commerce · Programación a medida

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%

Avance global = Σ (peso contractual o funcional del entregable × grado de terminación verificable)

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.

ProveedorDiseño incorrecto, falta de recursos, defectos, incumplimiento de hitos o entrega incompleta.
ClienteDatos tardíos, cambios, falta de validación, accesos no facilitados o decisiones bloqueadas.
TercerosAPI, hosting, licencia, pasarela, fabricante, normativa o servicio externo.
Causa compartidaRequisitos ambiguos, gobernanza insuficiente, aceptación informal o cambios sin control.

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.

Importante: el perito informático determina desviaciones, causalidad técnica y compatibilidad entre los hechos y las explicaciones de las partes. No declara culpabilidad jurídica ni resuelve el contrato; esa valoración corresponde al tribunal con el asesoramiento de los abogados y el conjunto de la prueba.

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.

Solicitar valoración del proyectoLlamar al 900 649 252