Contratar desarrollo software a medida en España: lo que debes revisar antes de firmar

Antes de cerrar un proyecto de software a medida, hay cuatro variables que determinan si el proyecto va a funcionar o va a convertirse en un problema: quién es el dueño del código, qué garantías de servicio incluye el contrato, qué entregables están comprometidos y cómo se valida que el sistema hace lo que tiene que hacer. Este artículo va directo a esos cuatro puntos.

Tabla de contenidos

• Propiedad del código: la cláusula que más se pasa por alto
• SLA: qué cubre y qué no cubre realmente
• Entregables: lo que debe estar escrito antes de empezar
• Proceso de pruebas: quién valida y con qué criterios
• Cumplimiento normativo: Verifactu y RGPD no son opcionales
• Señales de alerta antes de firmar
• TL;DR
• Lecturas recomendadas

Propiedad del código: la cláusula que más se pasa por alto

La propiedad intelectual del código es el punto que más empresas descubren demasiado tarde. Cuando contratas desarrollo de software a medida en España, el Texto Refundido de la Ley de Propiedad Intelectual (Real Decreto Legislativo 1/1996) establece que, salvo pacto expreso en contrario, el autor del código es quien lo desarrolla, no quien lo paga.

Eso significa que si el contrato no especifica explícitamente la cesión de derechos, el proveedor puede legalmente limitar tu capacidad de modificar, reutilizar o trasladar ese software a otro equipo.

Qué debe decir el contrato:

• Cesión total y exclusiva de los derechos de explotación del código al cliente una vez completado el pago.
• Entrega del código fuente en un repositorio accesible por el cliente (no solo el ejecutable o el desplegado).
• Cláusula de depósito en garantía (source code escrow) si el proveedor opera con código propietario parcial.
• Definición clara de qué partes del proyecto usan librerías de terceros con licencias abiertas (MIT, Apache 2.0) y cuáles son desarrollo original.

En España, sin cesión expresa en el contrato, el desarrollador retiene los derechos de autor sobre el software aunque hayas pagado el 100 % del presupuesto.

En Rowan Tech entregamos el código fuente completo de cada proyecto. No hay cláusulas de retención ni dependencia forzada de nuestro equipo para futuros cambios.

SLA: qué cubre y qué no cubre realmente

Un SLA (Service Level Agreement) define los compromisos de disponibilidad, tiempo de respuesta ante incidencias y consecuencias si no se cumplen. El problema es que muchos contratos de software a medida en España incluyen SLA redactados de forma tan amplia que son imposibles de exigir.

Métricas que debe incluir un SLA funcional:

• Disponibilidad garantizada: un 99,5 % de uptime equivale a un máximo de 43,8 horas de caída al año. Un 99,9 % equivale a 8,76 horas. Exige que el porcentaje esté escrito con su cálculo.
• Tiempo de respuesta por severidad: distingue entre incidencia crítica (sistema caído, pérdida de datos), alta (funcionalidad principal afectada) y media (problema puntual sin impacto en producción). Los tiempos de respuesta deben ser distintos para cada nivel.
• Ventana de mantenimiento programado: cuándo se realizan actualizaciones, con cuánto aviso y si computan o no como tiempo de indisponibilidad.
• Penalizaciones: qué ocurre si el proveedor no cumple los tiempos comprometidos. Si el SLA no incluye ninguna consecuencia, no es un SLA, es una declaración de intenciones.

Lo que suele faltar en los contratos que luego generan conflicto es la definición de “inicio del tiempo de respuesta”. Si el contrato dice “respondemos en 4 horas laborables” pero no aclara si el contador empieza cuando se notifica la incidencia o cuando el técnico la revisa, esa ambigüedad siempre juega en tu contra.

Entregables: lo que debe estar escrito antes de empezar

Un proyecto de desarrollo de software a medida sin entregables documentados es un proyecto sin hitos de control. Cuando algo va mal, no hay referencia objetiva para dirimir si el proveedor cumplió o no.

Lista de entregables mínimos que debe incluir la propuesta técnica:

1. Documento de requisitos funcionales firmado por ambas partes antes de arrancar el desarrollo.
2. Diseño técnico de la arquitectura (base de datos, integraciones, stack tecnológico elegido y justificación).
3. Prototipos o wireframes aprobados antes del desarrollo visual.
4. Código fuente versionado en repositorio compartido con el cliente (Git, acceso directo, no capturas).
5. Manual de usuario y documentación técnica de la API si aplica.
6. Informe de pruebas con casos de test ejecutados y resultados.
7. Plan de despliegue y procedimiento de rollback en caso de fallo en producción.

Cada entregable debe tener fecha comprometida, responsable asignado y criterio de aceptación. Sin criterio de aceptación, el cliente no tiene base para rechazar un entregable defectuoso.

Un contrato de software a medida sin criterios de aceptación escritos convierte cualquier disputa en una conversación subjetiva.

Puedes revisar cómo estructuramos los proyectos a medida en rowantech.es antes de cualquier conversación comercial.

Proceso de pruebas: quién valida y con qué criterios

El proceso de pruebas es el filtro entre lo que el equipo de desarrollo cree que funciona y lo que realmente funciona en tu operativa. En proyectos de software a medida para pymes españolas, los errores más costosos aparecen cuando no hay un protocolo de validación acordado.

Tipos de pruebas que deben estar contemplados:

• Pruebas unitarias: verifican que cada función del código hace lo que debe de forma aislada. El proveedor las ejecuta internamente.
• Pruebas de integración: verifican que los módulos del sistema se comunican correctamente entre sí y con sistemas externos (ERP, API de terceros, plataformas de facturación como Verifactu).
• Pruebas de aceptación de usuario (UAT): las ejecuta el equipo del cliente con datos reales o datos representativos, siguiendo un guion de casos previamente acordado.
• Pruebas de carga: si el sistema va a gestionar volúmenes altos de datos o usuarios concurrentes, el contrato debe especificar los umbrales esperados y los resultados aceptables.
• Pruebas de regresión: cada vez que se actualiza el software, se verifica que las funcionalidades previas siguen funcionando correctamente.

El punto crítico es que las pruebas UAT deben hacerlas personas de tu empresa, no el equipo del proveedor. Un proveedor no puede validar su propio trabajo con datos de producción que no conoce.

Establece también un periodo de garantía post-despliegue. Lo razonable en proyectos de software empresarial es entre 30 y 90 días en los que los errores detectados se corrigen sin coste adicional.

Cumplimiento normativo: Verifactu y RGPD no son opcionales

Si contratas software de gestión para una pyme española, el cumplimiento de Verifactu y el RGPD no es un extra que se añade después. Es parte del producto desde el diseño.

Verifactu (Real Decreto 1007/2023) obliga a los sistemas de facturación a generar registros de facturación encadenados e inalterables que pueden enviarse a la AEAT en tiempo real. Un software de gestión que no integre Verifactu desde el desarrollo inicial te obliga a adaptar o reemplazar el sistema más adelante.

RGPD: el proveedor que trata datos de tu empresa o de tus clientes actúa como encargado del tratamiento. El contrato debe incluir el Acuerdo de Tratamiento de Datos (DPA) con las cláusulas obligatorias del artículo 28 del RGPD: finalidad del tratamiento, medidas de seguridad, subencargados autorizados y protocolo de notificación de brechas.

Pregunta también dónde están los servidores. Los datos de ciudadanos europeos deben almacenarse en la UE o en países con decisión de adecuación de la Comisión Europea. En Rowan Tech los datos se alojan en infraestructura dentro de España.

Señales de alerta antes de firmar

Hay patrones que indican que un proyecto de software a medida va a dar problemas antes de que empiece:

• La propuesta técnica no diferencia entre requisitos funcionales y requisitos técnicos.
• El proveedor no puede explicar en lenguaje llano qué stack tecnológico va a usar y por qué.
• El contrato no menciona la propiedad intelectual del código.
• No hay hitos de pago ligados a entregables verificables; se pide todo o gran parte del presupuesto por adelantado.
• El SLA está redactado en horas sin distinguir por severidad de incidencia.
• El proveedor no tiene experiencia documentable en proyectos similares al tuyo en tamaño y sector.
• No existe ninguna cláusula sobre qué pasa si el proyecto se cancela a mitad: quién se queda con el código, qué se factura y qué no.

Ninguna de estas señales es subjetiva. Todas se comprueban leyendo el contrato y la propuesta técnica antes de firmar.

TL;DR

• La propiedad del código debe cederse expresamente por escrito; sin esa cláusula, el desarrollador retiene los derechos aunque hayas pagado.
• Un SLA útil define disponibilidad en porcentaje concreto, tiempos de respuesta por severidad y penalizaciones reales.
• Los entregables deben tener fecha, responsable y criterio de aceptación escrito antes de arrancar el desarrollo.
• Las pruebas UAT las hace el equipo del cliente, no el proveedor; incluye un periodo de garantía post-despliegue de 30 a 90 días.
• Verifactu y RGPD deben estar integrados desde el diseño, no añadidos como parche posterior.

Lecturas recomendadas

• Qué es un ERP a medida y cuándo tiene sentido para una pyme
• Gestión de almacén con trazabilidad en tiempo real: Rowan SGA
• Firma digital de albaranes con validez legal: RowanSign