Dos propuestas de software no son comparables si cada una interpreta un problema distinto. Antes de mirar el importe, iguala el perímetro: objetivo, usuarios, flujos, exclusiones, dependencias, entregables y criterios de aceptación.
Después compara cómo piensa entregar cada proveedor, qué evidencia ofrece y qué quedará bajo control de tu empresa. Esta guía no recomienda proveedores ni sustituye una revisión jurídica o técnica especializada.
Empieza con el mismo brief
Cada propuesta debe responder a una referencia común. Si todavía no existe, prepara primero el alcance y sus criterios de aceptación.
Si aún estás decidiendo entre configurar, integrar o desarrollar, resuelve antes esa elección con el marco de software a medida, SaaS y no-code. Comparar proveedores demasiado pronto puede hacer que cada propuesta responda a una vía distinta.
Entrega a todos los proveedores:
- problema y resultado buscado;
- usuarios y flujo principal;
- datos, sistemas e integraciones conocidas;
- restricciones y decisiones abiertas;
- elementos dentro y fuera;
- criterios mínimos de aceptación.
Si una propuesta incluye más funciones, eso no la hace mejor por defecto. Comprueba si resuelven el trabajo o amplían el proyecto sin una decisión explícita.
Separa mínimos, preferencias y alternativas
Clasifica cada criterio:
| Tipo | Lectura |
|---|---|
| Mínimo | Sin él, la propuesta no resuelve el trabajo o incumple una restricción real. |
| Preferencia | Aporta valor, pero admite compensaciones. |
| Alternativa | Resuelve el mismo objetivo mediante otro enfoque defendible. |
| Pendiente | Necesita evidencia o una decisión antes de puntuar. |
Esta separación evita descartar una solución útil por no copiar tu primera idea. También impide aceptar un mínimo como “fase futura” sin registrar el impacto.
Compara alcance, exclusiones y supuestos
Para cada propuesta pregunta:
- ¿qué recorridos y perfiles incluye?
- ¿qué datos e integraciones presupone disponibles?
- ¿qué tareas realizará el cliente?
- ¿qué migración, configuración o contenido queda fuera?
- ¿qué dependencia puede cambiar el alcance?
- ¿cómo se gestiona una variación?
No penalices una exclusión por estar escrita. Una exclusión visible puede ser más útil que una promesa amplia sin mecanismo.
Exige entregables y evidencia de avance
“Desarrollo de la plataforma” no explica qué recibirás ni cómo revisarás el progreso. Compara:
- fases y objetivo de cada fase;
- artefactos o versiones revisables;
- responsable del proveedor y del cliente;
- decisiones que bloquean el siguiente paso;
- demostraciones, pruebas o documentación;
- criterio de finalización.
Una propuesta puede trabajar de forma iterativa sin dejar el alcance invisible. Lo importante es saber qué referencia gobierna, cómo se prioriza y qué evidencia permite aceptar cada entrega.
Revisa pruebas y aceptación
Los criterios de aceptación deben conectar con el brief, no aparecer al final como una frase genérica.
Comprueba quién prepara datos de prueba, quién valida, qué entornos se usarán, cómo se registra un defecto y qué ocurre si un criterio no pasa. Distingue:
- aceptación del resultado acordado;
- corrección de defectos;
- cambio de alcance;
- mejora futura.
El BOE recoge en un convenio tecnológico concreto actas de entrega y conformidad asociadas a alcance, fechas, mantenimiento y soporte (BOE-A-2025-16134, observado el 29/08/2026). Es un ejemplo documental público, no una plantilla obligatoria para contratos privados.
Haz visibles todos los costes sin inventar tarifas
Compara categorías y supuestos, no una cifra aislada:
- definición y diseño;
- configuración o desarrollo;
- migración e integraciones;
- infraestructura, licencias y terceros;
- pruebas, formación y puesta en marcha;
- soporte, mantenimiento y evolución;
- trabajo que debe aportar tu equipo;
- salida o transferencia.
La guía de presupuesto de software a medida desarrolla estas partidas. C03 no da precios ni porcentajes universales.
Aclara cuentas, datos, código y documentación
No resumas todo como “propiedad”. Son objetos y accesos distintos:
- repositorio y código específico;
- componentes o licencias de terceros;
- cuentas de hosting, dominio y servicios;
- datos y formatos de exportación;
- documentación técnica y operativa;
- credenciales, permisos y procedimiento de entrega;
- capacidad de mantener o cambiar de proveedor.
Una resolución pública sobre cesión de software separa código fuente, derecho de uso, manuales, documentación y soporte (BOE-A-2025-5825, observado el 29/08/2026). Sirve para mostrar que son elementos distintos; sus condiciones no se trasladan automáticamente a una relación privada.
Cuando una condición tenga efecto contractual o jurídico, pide revisión profesional sobre el texto concreto. Este artículo solo ayuda a formular preguntas.
Evalúa continuidad y salida
Pregunta qué ocurre después de aceptar la primera versión:
- quién opera y monitoriza;
- qué soporte está incluido y qué queda fuera;
- cómo se priorizan cambios;
- qué documentación se mantiene;
- cómo se exportan datos;
- qué necesita otro equipo para continuar;
- qué depende de una cuenta o servicio del proveedor.
Interoperable Europe recomienda formular requisitos de interoperabilidad, portabilidad y salida para reducir dependencia en contratación pública (Interoperable Europe, observada el 29/08/2026). Es una guía para administraciones; aquí aporta preguntas de comparación, no obligaciones para una pyme.
Usa una matriz con evidencia
No puntúes “calidad” o “innovación” sin definición. Para cada criterio registra:
| Criterio | Mínimo | Respuesta | Evidencia | Duda/riesgo | Decisión |
|---|---|---|---|---|---|
| Flujo crítico | sí/no | qué incluye | demo, diagrama o criterio | exclusión | pasa/pendiente |
| Integración | condición | enfoque | documentación o prueba | acceso/API | pasa/pendiente |
| Aceptación | condición | método | casos y responsable | datos/entorno | pasa/pendiente |
| Salida | condición | entrega | formato, cuentas y docs | dependencia | pasa/pendiente |
Las ponderaciones ayudan solo si los mínimos ya están resueltos. Guarda también preguntas, respuestas y motivo de la decisión para no reconstruirla después.
Señales de una propuesta difícil de comparar
- promete resultado sin describir el flujo;
- oculta exclusiones o trabajo del cliente;
- usa una cifra cerrada con demasiados supuestos pendientes;
- no conecta entregables con aceptación;
- mezcla soporte, garantía, mantenimiento y evolución;
- no aclara cuentas, datos o documentación;
- responde a preguntas con adjetivos en vez de evidencia.
La solución no es elegir automáticamente la propuesta más extensa. Es hacer visibles las diferencias que cambian riesgo, control y utilidad.