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.
Respuesta rápida
¿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.
Qué peritamos
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, API, 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 la 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
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 el 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. En nuestro blog explicamos más casos de incumplimiento en contratos de software.
Base de comparación
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 una funcionalidad terminada. |
| Sistema desplegado | Qué funciona en el entorno de pruebas o de producción. | Deben identificarse la versión, la configuración y las 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.
Grado de 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 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, los pagos y los 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, la seguridad, el aislamiento de clientes y la 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 terminado al cien por cien.
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.
Causalidad técnica
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 que «el cliente no colaboró», identifica hechos concretos y su impacto técnico.
-
Proveedor
Diseño incorrecto, falta de recursos, defectos, incumplimiento de hitos o entrega incompleta.
-
Cliente
Datos tardíos, cambios, falta de validación, accesos no facilitados o decisiones bloqueadas.
-
Terceros
API, hosting, licencias, pasarela, fabricante, normativa o servicio externo.
-
Causa compartida
Requisitos 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 los 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 la 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.
Qué necesitamos
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 los cambios posteriores. No borre 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 una exportación verificable puede conservar el estado de la web, el servidor o el repositorio en una fecha concreta.
Metodología
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 los casos relevantes y 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 la arquitectura, el historial, las dependencias, la calidad, las pruebas y la 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 la metodología, la matriz de cumplimiento, los resultados, las limitaciones y las conclusiones. Si es necesario, ratificamos ante el órgano judicial.
Casos habituales
Ejemplos de peritación por tipo de proyecto
-
Tienda online que no puede vender
Existen 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, la documentación, la cobertura funcional, las dependencias y el coste técnico aproximado para continuar o rehacer.
-
WordPress con desarrollo defectuoso
Se separan los problemas del núcleo, la plantilla, los plugins, la personalización, el hosting, el mantenimiento y el uso posterior del cliente.
Otros servicios
Certificación, plagio, ataques y valoración de páginas web
Además de los conflictos de desarrollo, mantenemos los servicios tradicionales de peritación de páginas web: 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ídas, redirecciones y afectación a los 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 sus límites.
-
Contrapericial
Revisión crítica de informes sobre software, webs, código o incidentes aportados por la otra parte.
Si ya existe un informe contrario, consulte nuestro servicio de informe contrapericial informático. Puede ver un ejemplo real en el caso de certificación del plagio de un sitio web. 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 resume cómo se transforma un problema tecnológico en un informe técnico estructurado, comprensible y útil para el procedimiento.
Para abogados
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 el código, los datos, las credenciales, la documentación y las 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, los daños y la resolución deben ser valorados por la dirección letrada.
Plazo y precio de la peritación
Dependen del volumen contractual, el número de módulos, repositorios, entornos e integraciones, los datos, el periodo del proyecto, las pruebas necesarias, el acceso a los sistemas, la urgencia y la 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
Preguntas frecuentes sobre la peritación de páginas web y software
¿Tiene un proyecto en disputa? Llámenos al 900 649 252 y le orientamos.
¿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 sus 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 la oferta, las comunicaciones, las demos, los tickets, la conducta posterior y la 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 del proveedor, el cliente y terceros. La responsabilidad jurídica definitiva corresponde al tribunal y exige interpretar el contrato, la prueba y la normativa.
¿Necesitan acceder al código fuente?
No siempre, pero puede ser esencial para valorar el avance, la calidad, el historial o la posibilidad de continuar. Otras cuestiones pueden resolverse con el sistema, la documentación, los logs y las 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 el mantenimiento y la 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 los módulos contratados, la parametrización, los desarrollos, la migración, los permisos, los procesos, los informes, las integraciones, la documentación y el funcionamiento en el entorno acordado.
¿Peritan 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 analizan la reutilización del código, la arquitectura, la deuda técnica, la documentación, las pruebas, las dependencias y los riesgos. La decisión empresarial también depende del coste, los plazos y la 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 de datos, configuración, logs, capturas y accesos antes de migrar o modificar el sistema.
¿El informe puede usarse en juicio?
Se redacta para explicar la metodología, los hallazgos, las limitaciones y las conclusiones, con posibilidad de ratificación. La valoración final corresponde al órgano judicial.
¿Hacen contrapericiales de informes sobre software?
Sí. Revisamos el alcance, las evidencias, las pruebas, los porcentajes, los criterios, la 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
- Código Civil (texto consolidado)
- Ley 1/2000, de Enjuiciamiento Civil
- Texto refundido de la Ley General para la Defensa de los Consumidores y Usuarios: conformidad de contenidos y servicios digitales.
- Ley de Propiedad Intelectual: programas de ordenador.
- NIST Secure Software Development Framework (SSDF): prácticas de desarrollo seguro.
La aplicación jurídica depende siempre del contrato y del caso.
¿Su proyecto web, CMS o ERP no se ha entregado como se contrató?
Cuéntenos qué se pactó, qué se ha pagado, qué funciona, qué falta y cuál es la fecha límite. Le indicaremos qué documentación preservar y qué preguntas puede responder una peritación proporcionada.
