Para comparar presupuestos de software a medida, no empieces por ordenar las propuestas de menor a mayor precio. Primero comprueba si todas describen el mismo problema, el mismo alcance y las mismas responsabilidades. Dos ofertas con importes parecidos —o muy distintos— pueden incluir productos muy diferentes.
La forma más útil de decidir es pedir una base común de información, puntuar cada propuesta con criterios verificables y revisar el coste previsto durante la vida de la solución. El precio inicial importa, pero no explica por sí solo qué recibirá la empresa, qué tendrá que asumir internamente ni qué costes pueden aparecer después.
Por qué el presupuesto más barato no siempre es comparable
Un proveedor puede incluir análisis, diseño, integraciones, migración de datos, pruebas, despliegue, formación y soporte. Otro puede presupuestar solo una parte del desarrollo y dejar el resto como servicios posteriores, dependencias del cliente o cambios de alcance. En ambos casos puede hablarse de una «aplicación», pero no se está comprando necesariamente lo mismo.
Antes de valorar una diferencia de precio, identifica qué cubre cada propuesta en estas fases:
- análisis y definición de requisitos;
- diseño funcional y técnico;
- desarrollo e integración con ERP, CRM o servicios externos;
- migración, depuración o carga inicial de datos;
- pruebas, corrección de incidencias y aceptación;
- despliegue, configuración y formación;
- soporte posterior, mantenimiento y evolución.
La calidad también debe formar parte de la comparación. El modelo de ISO/IEC 25010:2023 sirve como referencia para concretar requisitos de calidad de productos y sistemas software. No certifica al proveedor por mencionarlo, pero ayuda a convertir conceptos genéricos como «calidad» en aspectos comprobables: fiabilidad, rendimiento, usabilidad, compatibilidad, seguridad, mantenibilidad y capacidad de evolución.
Si las propuestas no contienen la misma información, solicita una aclaración antes de negociar. Comparar cifras sin homogeneizar alcance suele convertir la contratación en una subasta, cuando en realidad es una decisión sobre riesgo operativo, continuidad y dependencia tecnológica.
Define una base común antes de pedir o analizar ofertas
No necesitas tener cada detalle resuelto para pedir presupuesto, pero sí un punto de partida compartido. Describe el proceso actual, el problema que se quiere resolver y los resultados que debería permitir la aplicación.
Incluye, como mínimo:
- usuarios previstos y sus roles;
- funcionalidades prioritarias y flujos principales;
- datos que se consultarán, crearán o modificarán;
- integraciones necesarias y sistemas implicados;
- dispositivos, entornos o restricciones de uso conocidos;
- requisitos de seguridad, permisos y trazabilidad;
- dependencias que debe aportar la empresa, como acceso a sistemas, datos de prueba o responsables de validación.
Pide a todos los proveedores que separen de forma explícita los supuestos, exclusiones, entregables, fases, calendario propuesto, equipo asignado, participación esperada de tu empresa y condiciones para los cambios. También conviene que indiquen qué requisitos permanecen abiertos y cómo se valorarán si se concretan más adelante.
Los criterios de aceptación son especialmente importantes. ISO/IEC 25030 plantea que los requisitos de calidad sean verificables y medibles para utilizarlos en especificaciones, viabilidad, contratos y concursos. Trasladado a una propuesta, cada entrega debe poder responder a una pregunta sencilla: ¿qué se probará y qué evidencia demostrará que se acepta?
Usa una matriz de comparación con criterios y evidencias
Una matriz evita que una presentación comercial convincente o una cifra baja dominen toda la decisión. Define los pesos según el contexto de tu empresa: una aplicación que gestione datos sensibles puede dar más importancia a seguridad y controles; una herramienta interna conectada a varios sistemas puede priorizar integraciones, mantenibilidad y continuidad.
| Criterio | Qué comparar | Evidencia que pedir | Puntuación |
|---|---|---|---|
| Alcance y comprensión | Cómo entiende el proceso, qué cubre y qué deja fuera. | Requisitos, supuestos, exclusiones y flujos descritos. | Según tu peso |
| Solución técnica | Arquitectura, integraciones, compatibilidad y evolución. | Diseño técnico, responsabilidades y dependencias. | Según tu peso |
| Calidad y pruebas | Rendimiento, fiabilidad, usabilidad, mantenibilidad y aceptación. | Plan de pruebas, criterios de aceptación y resultados previstos. | Según tu peso |
| Seguridad | Accesos, controles, pruebas, configuración y documentación. | Requisitos, pruebas y entregables de seguridad. | Según tu peso |
| Equipo y método | Perfiles, responsabilidades, comunicación y gestión de riesgos. | Equipo asignado, fases, reuniones y mecanismos de seguimiento. | Según tu peso |
| Soporte y continuidad | Incidencias, cambios, mantenimiento y condiciones posteriores. | Alcance del soporte, tarifas y procedimiento de atención. | Según tu peso |
| Propiedad y portabilidad | Código, repositorio, documentación, datos y salida del proveedor. | Cláusulas, inventario de entregables y plan de transición. | Según tu peso |
| Coste total previsto | Desarrollo, terceros, infraestructura, mantenimiento y transición. | Desglose de partidas recurrentes y no recurrentes. | Según tu peso |
No hay pesos universales. Lo importante es que todas las ofertas se valoren con la misma escala y que la puntuación vaya acompañada de observaciones: qué está documentado, qué depende de una confirmación y qué queda sin evidencia.
Calidad y seguridad deben bajar a requisitos concretos
Una propuesta sólida no se limita a afirmar que la aplicación será escalable, segura o fácil de usar. Explica qué controles, pruebas y entregables respaldarán esas afirmaciones.
Para seguridad, OWASP ASVS ofrece requisitos para verificar controles de seguridad en aplicaciones. Puede utilizarse como referencia para acordar exigencias proporcionales al caso, sin que citarlo equivalga a una certificación o garantía del proyecto.
También es razonable pedir cómo se documentarán los resultados de las pruebas, cómo se revisará el código cuando proceda y qué directrices de configuración segura se entregarán. El anexo de OWASP para contratos de software seguro recoge estos elementos como posibles compromisos contractuales.
Compara el coste total, no solo la cifra de desarrollo
El coste total de propiedad de un software a medida no puede calcularse con una cifra universal. Depende del alcance, las integraciones, la complejidad de los datos, los requisitos de calidad y seguridad, los servicios de terceros y la forma en que la solución se mantendrá.
Al revisar un presupuesto, separa estas partidas:
- análisis, diseño y desarrollo;
- integraciones y responsabilidades sobre cada sistema externo;
- migración o preparación de datos;
- pruebas, despliegue y formación;
- infraestructura, servicios externos y licencias de terceros;
- mantenimiento correctivo, adaptativo y evolutivo;
- tarifas y procedimiento para cambios de alcance;
- coste de exportar datos, transferir conocimientos o cambiar de proveedor.
Distingue también el mantenimiento correctivo, destinado a resolver incidencias; el adaptativo, necesario cuando cambian entornos o dependencias; y el evolutivo, que añade o modifica capacidades. Una oferta puede incluir uno, varios o ninguno. Si no queda escrito, no conviene darlo por supuesto.
La salida del proveedor merece una revisión específica. Confirma quién tendrá acceso al repositorio, qué documentación se entregará, cómo se conservarán las credenciales, si existirán copias de seguridad y cómo se exportarán los datos. Para profundizar en esa lista, consulta qué debe entregar un desarrollador de software a medida: código, documentación y accesos.
Qué cambia según el modelo de contratación
El mejor modelo depende de la claridad del alcance y de la incertidumbre que exista. Más que elegir una modalidad por costumbre, compara qué riesgo asume cada parte y cómo se controlan los cambios.
Precio cerrado
Puede facilitar la previsión inicial cuando el alcance está bien definido. Exige que la propuesta detalle funcionalidades, supuestos, exclusiones, entregables, criterios de aceptación y un procedimiento para los cambios. Sin esa precisión, el precio cerrado puede ocultar desacuerdos posteriores sobre qué estaba incluido.
Bolsa de horas
Puede encajar cuando todavía hay incertidumbre o se necesita trabajo continuo. Pide tarifa por perfil, mecanismo de aprobación, información sobre horas consumidas, límites de gasto, frecuencia de seguimiento y entregables esperados. No basta con conocer el volumen de horas: hay que saber qué decisiones o resultados se espera obtener con ellas.
Desarrollo por fases
Permite reducir incertidumbre antes de comprometer todo el desarrollo. Cada fase debe tener un objetivo concreto, entregables, criterios de revisión y una decisión explícita sobre la siguiente etapa. Una fase inicial de análisis puede ser útil si las integraciones, los datos o los flujos de trabajo aún no están suficientemente definidos.
Modelo híbrido
Combina elementos cerrados con actividades sujetas a descubrimiento. Por ejemplo, se puede acordar un alcance definido para una primera entrega y mantener el análisis de una integración incierta bajo una modalidad distinta. La propuesta debe dejar clara esa separación para evitar que el riesgo quede oculto tras una cifra única.
Preguntas para descubrir un presupuesto incompleto
Lleva estas preguntas a las reuniones con proveedores y pide que las respuestas queden reflejadas en la propuesta o en sus anexos:
- ¿Qué queda expresamente fuera de la propuesta?
- ¿Qué supuestos deben cumplirse para mantener alcance, precio o calendario?
- ¿Quién proporciona y mantiene cada integración con ERP, CRM o servicios externos?
- ¿Cómo se validan y aceptan las entregas?
- ¿Qué ocurre si aparecen requisitos nuevos o cambia una dependencia externa?
- ¿Qué pruebas se ejecutarán y qué evidencias se entregarán?
- ¿Qué recibe la empresa al finalizar: código, repositorio, documentación, configuraciones, credenciales, copias y datos exportables?
- ¿Qué componentes de terceros o código reutilizable se emplearán y qué restricciones de licencia tienen?
- ¿Qué soporte y mantenimiento se ofrecen después de la puesta en marcha?
- ¿Qué ayuda se prestaría en una transición a otro proveedor?
Estas preguntas también ayudan a detectar un problema habitual: una propuesta no es necesariamente mejor por ser más extensa, pero debe permitir conocer qué se compra, cómo se comprobará y qué responsabilidades conserva la empresa.
Seguridad, datos personales y propiedad: puntos que deben quedar por escrito
Cuando el proveedor accede a datos personales por cuenta de la empresa, no es suficiente una referencia genérica a la privacidad. La relación puede requerir un contrato de encargo del tratamiento. La AEPD indica que este contrato debe recoger, entre otros elementos, objeto, duración, finalidad, tipos de datos, categorías de interesados, instrucciones documentadas, subcontratación y asistencia en el ejercicio de derechos.
La aplicabilidad concreta depende de cómo se trate la información, de las subcontrataciones, de posibles transferencias internacionales y de las medidas necesarias en el caso particular. Para cerrar obligaciones concretas, conviene contar con revisión jurídica especializada.
También debe aclararse la titularidad y el alcance de los derechos sobre código fuente, documentación, diseños, bases de datos, configuraciones y componentes reutilizables. En España, los programas de ordenador están protegidos por propiedad intelectual; pagar un desarrollo no implica automáticamente recibir todos los derechos o el código fuente si no se pacta de forma clara. El texto refundido de la Ley de Propiedad Intelectual es la referencia legal de partida, pero las condiciones concretas del contrato requieren análisis profesional.
Por último, comprueba si existen requisitos de accesibilidad aplicables al producto o servicio. La Directiva (UE) 2019/882 se aplica desde el 28 de junio de 2025 a determinados productos y servicios, incluidos ciertos supuestos de comercio electrónico, aplicaciones móviles, sitios web vinculados y software dedicado. No se aplica automáticamente a cualquier software empresarial: depende del servicio, el público, el mercado y las excepciones aplicables.
Señales de una propuesta sólida y señales de riesgo
| Propuesta sólida | Señal de riesgo |
|---|---|
| Describe el proceso y plantea dudas concretas antes de cerrar alcance. | Usa funcionalidades genéricas sin relacionarlas con el problema de negocio. |
| Explicita supuestos, exclusiones y dependencias. | Deja términos ambiguos como «todo incluido» sin detalle verificable. |
| Divide el trabajo en fases, entregables y criterios de aceptación. | No indica cómo se probará ni cuándo se considerará terminada una entrega. |
| Identifica riesgos de integraciones, datos y participación del cliente. | Da por resueltas dependencias que todavía no se han analizado. |
| Detalla soporte, mantenimiento, propiedad y salida. | Habla de soporte o seguridad como eslóganes, sin condiciones ni evidencias. |
Un precio bajo no demuestra por sí mismo que una propuesta sea deficiente. Puede responder a un equipo eficiente, a un alcance más reducido, a componentes ya disponibles o a una estrategia comercial distinta. La cuestión es si puedes verificar qué incluye, qué no incluye y qué riesgo asume cada parte.
Del mismo modo, una propuesta cara no demuestra una calidad superior si no justifica sus decisiones, entregables y responsabilidades. Si estás valorando si la solución debe ser a medida o puede resolverse con una herramienta existente, puede ayudarte esta guía sobre cuándo necesitas una aplicación personalizada en lugar de un software genérico.
Elige la propuesta con el riesgo mejor explicado
Puntúa todas las ofertas sobre la misma base, anota qué afirmaciones tienen respaldo documental y solicita aclaraciones antes de convertir la negociación en una conversación exclusiva sobre descuento. Descarta o revisa las propuestas que no permitan saber qué se entrega, cómo se acepta, qué costes posteriores existen y qué ocurrirá si la empresa necesita cambiar de proveedor.
Cuando persistan diferencias relevantes de alcance, una fase inicial de análisis puede ser una decisión más segura que contratar el desarrollo completo con requisitos todavía ambiguos. El objetivo no es encontrar el presupuesto más bajo, sino la propuesta que haga más comprensibles el trabajo, las responsabilidades y los riesgos que tu empresa está asumiendo.
Preguntas frecuentes
¿Cómo comparar presupuestos de software a medida correctamente?
Pide a todos los proveedores una misma base de información y compara alcance, supuestos, exclusiones, entregables, criterios de aceptación, integraciones, pruebas, soporte, propiedad y coste total previsto. Después puntúa cada propuesta con una matriz adaptada a las prioridades de tu empresa, sin usar el precio como único criterio.
¿Qué debe incluir un presupuesto de software a medida?
Debe indicar al menos el alcance funcional, las exclusiones, los supuestos, las fases, los entregables, las integraciones, las dependencias del cliente, los criterios de aceptación, las pruebas, el despliegue, el soporte, el mantenimiento y las condiciones aplicables a cambios de alcance.
¿Qué es el coste total de propiedad de un software a medida?
Es la valoración de los costes previsibles más allá del desarrollo inicial. Puede incluir análisis, diseño, integraciones, migración de datos, pruebas, infraestructura, licencias de terceros, soporte, mantenimiento, evolución y una posible transición a otro proveedor. No existe una cifra universal porque depende de cada proyecto.
¿El proveedor debe entregar el código fuente?
No debe darse por supuesto. La propuesta y el contrato deben precisar qué se entrega y qué derechos recibe la empresa sobre el código fuente, repositorio, documentación, diseños, bases de datos, configuraciones y componentes reutilizables. Para una decisión contractual concreta conviene una revisión jurídica especializada.
¿Qué modelo de contratación conviene para desarrollar software a medida?
Depende de la claridad del alcance y de la incertidumbre del proyecto. El precio cerrado requiere requisitos y cambios muy definidos; una bolsa de horas exige seguimiento de consumo y entregables; el trabajo por fases permite revisar decisiones antes de continuar; y un modelo híbrido puede separar partes conocidas de aspectos aún inciertos.
¿Qué pasa si el proveedor trata datos personales de la empresa?
Hay que analizar si actúa como encargado del tratamiento y formalizar la relación conforme al caso aplicable. Deben revisarse, entre otros aspectos, el objeto, la finalidad, las instrucciones, los tipos de datos, las subcontrataciones y las medidas de seguridad. La AEPD ofrece orientación general, pero no sustituye el análisis jurídico del caso concreto.
¿Quieres revisar una propuesta de software antes de contratar?
Podemos analizar el alcance, las integraciones, los entregables y la continuidad para detectar qué dudas conviene resolver antes de elegir proveedor.
