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.
Conviene acordar criterios, responsables y evidencias antes de la entrega. La guía de aceptación de NASA trata estos elementos por entrega; aquí se adaptan como preguntas para el encargo, sin trasladar su formalidad.
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. Los importes del ejemplo de esta guía son ficticios y no representan una tarifa de mercado.
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.
La Ley de Propiedad Intelectual distingue los derechos y modalidades que se ceden; recibir una aplicación, sus archivos y un permiso de uso no describe por sí solo el mismo acuerdo. Concreta qué necesitas poder hacer y que el texto identifique esas condiciones.
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.
Dos propuestas que parecen hablar de la misma aplicación
Vamos a comparar Cuaderno de equipo, una aplicación interna para guardar decisiones de proyectos con tres roles. Las propuestas A y B, sus importes y sus condiciones son ficticios; el ejemplo sirve para aprender a leer diferencias.
Ambas mencionan proyectos, decisiones, búsqueda y acceso del equipo. Sin embargo, la misma lista resumida puede ocultar estas diferencias:
| Elemento del alcance común | Propuesta A | Propuesta B |
|---|---|---|
| Crear y editar proyectos y decisiones | Incluido | Incluido |
| Buscar y filtrar | Incluido | Incluido |
| Tres roles con permisos comprobados en servidor | No consta | Incluido |
| Acceso del equipo | Incluido, sin concretar recuperación | Incluido, con recuperación definida |
| Exportación JSON de los campos acordados | Excluido | Incluido |
| Documento Markdown legible | Incluido | Incluido |
| Recuperación comprobada de una copia | No consta | Incluido |
| Pruebas y corrección de defectos acordados | No consta; menciona revisión final | Incluido |
| Código y condiciones de uso | No consta; dice «la aplicación será tuya» | Incluido y descrito |
| Arranque por otra persona con documentación | No consta | Incluido |
No consta no significa que el proveedor se niegue a hacerlo. Significa que la propuesta todavía no ofrece una respuesta concreta que puedas comparar. Y Incluido indica lo que se compromete a entregar, no que ya haya demostrado hacerlo bien.
Igualar la forma de expresar el dinero
La A presenta 5.600 € netos de construcción. La B presenta 8.470 € con el impuesto del 21 % del ejercicio: equivalen a 7.000 € netos. Si comparas 5.600 con 8.470 sin corregir la base, exageras la diferencia de inversión inicial.
Después vienen las cuotas:
| Importe conocido | A, neto | B, neto |
|---|---|---|
| Construcción inicial | 5.600 € | 7.000 € |
| Alojamiento, por año | 720 € | 420 € |
| Dominio, por año | 18 € | 18 € |
| Servicio de copias, por año | No consta | 96 € |
| Mantenimiento, por año | No consta | 1.200 € |
| Suma conocida del primer año | 6.338 € | 8.734 € |
En B, el mantenimiento del ejemplo cubre hasta dos horas mensuales para las tareas acordadas. No implica mejoras ilimitadas ni atención continua. En A, no conocer esa condición impide tratar el soporte como equivalente.
La diferencia entre las sumas es 2.396 €, pero aún no describe un ahorro comparable. La A excluye JSON y no concreta otras unidades necesarias. Tampoco debes añadirle un precio inventado para completar la tabla: pide que describa y valore la alternativa que falte.
El presupuesto trabajado permite reconstruir los 7.000 € y los 1.734 € recurrentes de B. En cualquier oferta real conviene leer la base fiscal, la frecuencia y lo incluido en cada partida.
Las preguntas que salen de esta tabla
El siguiente paso no es votar qué columna parece mejor. Es enviar preguntas concretas:
Para comparar ambas propuestas sobre el mismo alcance, necesito concretar cuatro puntos: las acciones permitidas por cada rol; qué datos y relaciones incluye la exportación; cómo se comprobará una recuperación; y qué código, instrucciones y condiciones de uso recibiremos. Indica qué está incluido, qué quedaría fuera y qué cambiaría el importe o la forma de entrega.
Si una respuesta propone otro enfoque que cumple el objetivo, conserva esa alternativa. Por ejemplo, puede ofrecer un formato distinto que tu equipo sí sabe utilizar. Cambia el criterio común con una razón explícita antes de dar por equivalentes las opciones.
Si el proveedor dice que una condición necesita una comprobación previa, pide qué pregunta resolverá, qué se entregará y cómo afectará a la siguiente decisión. Una incógnita reconocida no es lo mismo que una obligación ya incluida.
De la matriz a la decisión
Una propuesta más completa en papel puede fallar al ejecutar, y una más breve puede aclararse con respuestas precisas. La matriz organiza lo que sabes; la decisión también requiere entender cómo se construirá, revisará y continuará el trabajo.
Usa la matriz de comparación editable o el comparador de presupuestos para conservar alcance, partidas y dudas. No hace falta introducir nombres reales de proveedores ni información confidencial para aprender con el ejemplo.
Antes de aceptar una frase como «todo será tuyo», revisa propiedad, accesos y continuidad del software. Puedes recorrer todas las decisiones en la guía para encargar software a medida.
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.