Checklist para elegir software a medida: guía práctica para directivos

Para elegir software a medida en España, aplica esta checklist operacional y el marco de decisión de 5 pasos antes de pedir una sola propuesta. El proceso completo, desde la definición del problema hasta la firma del contrato, debería durar unas semanas si tu equipo sigue los pasos en orden.

Estas son las acciones que debes tomar ahora mismo:

• Define el problema en términos de negocio, no de tecnología: «perdemos 3 horas diarias conciliando datos entre dos sistemas» es un requisito; «necesitamos una API REST» no lo es todavía.
• Prepara una matriz de requisitos con columnas de prioridad (crítico / deseable), área solicitante y métrica de validación antes de hablar con ningún proveedor.
• Crea una shortlist de 3 a 5 proveedores con proyectos en producción verificables en España.
• Exige una prueba de concepto (PoC) con datos reales, no una demo con datos de ejemplo, y fija criterios de éxito por escrito antes de empezarla.
• Calcula el TCO a 3 años sumando licencias, implementación, integraciones, formación, mantenimiento y migración futura.
• Revisa las cláusulas de propiedad del código y acceso al repositorio antes de firmar cualquier acuerdo.

Elegir software a medida sin una checklist estructurada es la causa más frecuente de proyectos que se entregan tarde, superan el presupuesto o quedan atrapados en un proveedor que no puedes abandonar. Un proceso de selección bien documentado protege a tu empresa tanto técnica como legalmente.

Si sigues este proceso, al cabo de 8 semanas tendrás una decisión documentada, un contrato con cláusulas de salida y un proveedor que ya ha demostrado que puede trabajar con tus datos reales.

Puntos clave

Elegir software a medida en España requiere PoC con datos reales, TCO calculado a 3 años, cláusula de propiedad del código y un contrato con condiciones de salida claras antes de firmar.

Tabla de contenidos

• ¿Qué criterios mínimos debe cumplir cualquier proveedor en el primer filtro?
• ¿Cómo estructurar un proceso de decisión profesional en 5 pasos?
• ¿Cómo escribir los requisitos de tu proyecto para comparar opciones con objetividad?
• ¿Cómo verificar la experiencia técnica real de un proveedor antes de comprometerte?
• ¿Qué preguntas técnicas revelan si la arquitectura aguanta el crecimiento de tu empresa?
• ¿Qué cláusulas contractuales evitan que quedes atrapado con un proveedor?
• ¿Cómo estructurar una PoC que te dé información real para decidir?
• ¿Qué niveles de prueba debes exigir para protegerte después del lanzamiento?
• ¿Qué requisitos de seguridad y cumplimiento son obligatorios en España?
• ¿Qué negociar en el SLA y el mantenimiento para no llevarte sorpresas a largo plazo?
• ¿Cómo calcular el coste real del software a medida más allá del precio inicial?
• ¿Cómo verificar referencias y qué señales de alerta descartan a un proveedor?
• Lo que los procesos de selección suelen ignorar y acaba costando caro
• Codentix acompaña cada paso del proceso, desde el análisis hasta el mantenimiento
• Fuentes

¿Qué criterios mínimos debe cumplir cualquier proveedor en el primer filtro?

Usa esta lista como primer filtro antes de pedir propuestas formales. Si un proveedor no supera estos puntos, descártalo sin invertir más tiempo.

• Entrega por fases con sprints de 2 semanas y demos periódicas al cliente.
• Modelo de precio claro: precio fijo, tiempo y material o equipo dedicado, con desglose de partidas.
• Al menos dos casos de éxito verificables en España con empresa de referencia contactable.
• Stack tecnológico moderno y documentado (lenguajes, frameworks, infraestructura en la nube).
• SLA básico por escrito: tiempo de respuesta ante incidencias críticas, cobertura horaria y canal de contacto.
• Política explícita de propiedad del código: cesión total o licencia perpetua al cliente.
• Cumplimiento GDPR / AEPD: disposición a firmar un acuerdo de tratamiento de datos (DPA).
• Equipo de implementación propio, no subcontratado al 100 %.

Cómo usarla: aplica esta lista en la primera llamada o reunión de presentación. Cualquier «no» o «depende» sin explicación concreta es motivo de descarte o de solicitar aclaración inmediata por escrito.

Consejo profesional: Pide al proveedor que rellene esta lista por escrito antes de la reunión. Los que tienen respuestas claras lo harán en menos de 24 horas; los que tardan una semana ya te están diciendo algo.

¿Cómo estructurar un proceso de decisión profesional en 5 pasos?

El marco de 5 pasos que sigue es reproducible, documentable y defendible ante dirección o consejo de administración.

1. Define el problema en términos de negocio y KPIs claros. Describe qué proceso falla, cuánto cuesta ese fallo (tiempo, dinero, errores) y qué métrica concreta mejorará con la solución. Sin este paso, cualquier propuesta técnica es incomensurable. Consulta la guía sobre cuándo merece la pena invertir en software a medida para calibrar si tu caso encaja.

2. Documenta requisitos críticos vs. deseables y asígnales pesos. Un requisito crítico bloquea el proyecto si no se cumple; uno deseable añade valor pero no es excluyente. Asigna un peso numérico a cada categoría (por ejemplo, seguridad: 30 %, funcionalidad: 40 %, integración: 20 %, usabilidad: 10 %) para poder puntuar propuestas de forma objetiva.

3. Crea una shortlist de 3 a 5 opciones con criterios de filtrado explícitos. Los criterios de filtrado deben incluir: proyectos en producción en España, equipo técnico propio, referencias contactables y disposición a hacer PoC. Descarta antes de invitar a proponer.

4. Realiza una PoC con datos reales y criterios de éxito definidos por escrito. Una demo con datos de ejemplo no revela fricciones reales. La PoC debe usar un subconjunto de tus datos de producción, durar entre 2 y 4 semanas, y tener criterios de aceptación medibles acordados antes de empezar.

5. Calcula el TCO a varios años e incluye cláusulas contractuales protectoras. El precio de implementación es solo una parte del coste real. Suma mantenimiento, evolutivos, formación y migración futura para comparar opciones en igualdad de condiciones.

Consejo profesional: Documenta cada paso en un registro interno. Si el proyecto fracasa o el proveedor incumple, esa documentación es tu protección legal y tu punto de partida para renegociar.

¿Cómo escribir los requisitos de tu proyecto para comparar opciones con objetividad?

Transformar objetivos de negocio en requisitos medibles es el trabajo previo que más tiempo ahorra durante la evaluación. Sin esta matriz, cada proveedor interpreta el encargo de forma diferente y las propuestas son incomparables.

La matriz de requisitos ponderada recomendada tiene estas columnas:

Errores frecuentes al definir el alcance:

• Escribir requisitos demasiado genéricos («que sea fácil de usar») sin métrica de validación.
• Confundir deseos con requisitos: «sería bonito tener» no es lo mismo que «el negocio se para sin esto».
• Olvidar requisitos no funcionales: rendimiento bajo carga, disponibilidad, tiempo de recuperación ante fallos.
• No incluir requisitos de cumplimiento: registro de actividades de tratamiento (AEPD), retención de datos según normativa fiscal española, y trazabilidad de accesos.

¿Cómo verificar la experiencia técnica real de un proveedor antes de comprometerte?

Las afirmaciones de marketing no bastan. Necesitas evidencia técnica verificable, y hay formas concretas de obtenerla sin violar acuerdos de confidencialidad.

Lo que debes pedir antes de avanzar en el proceso:

• Proyectos en producción: nombre de la empresa cliente (con permiso), URL del sistema en uso o métricas de operación (uptime, volumen de transacciones).
• Acceso lector a un repositorio de muestra: no necesitas ver código propietario; un proyecto de código abierto o una muestra anonimizada revela calidad de commits, cobertura de tests y documentación.
• Arquitectura de ejemplo documentada: diagrama de componentes, decisiones técnicas y justificación de las mismas.
• Métricas de operación: tiempo medio de resolución de incidencias, porcentaje de entregas a tiempo en los últimos 12 meses.

Preguntas técnicas clave para la reunión de evaluación:

• ¿Qué stack utilizáis y por qué? ¿Cómo gestionáis las actualizaciones de dependencias?
• ¿Tenéis pipeline de CI/CD automatizado? ¿Qué herramientas usáis (GitHub Actions, GitLab CI, Jenkins)?
• ¿Cómo gestionáis los entornos de desarrollo, preproducción y producción?
• ¿Qué cobertura de pruebas automatizadas exigís internamente?

Para verificar referencias técnicas sin violar NDA, pide hablar directamente con el responsable técnico del cliente anterior, no solo con el comercial del proveedor. Una llamada de 20 minutos con el CTO o el responsable de TI del proyecto anterior vale más que diez páginas de casos de éxito redactados por el proveedor.

Consejo profesional: Pide al proveedor que describa el fallo técnico más grave que ha tenido en un proyecto y cómo lo resolvió. La calidad de esa respuesta dice más sobre su madurez que cualquier lista de tecnologías.

¿Qué preguntas técnicas revelan si la arquitectura aguanta el crecimiento de tu empresa?

Una solución que funciona para 50 usuarios puede colapsar con 500. Estas preguntas concretas, respaldadas por la revisión de criterios contractuales y técnicos, revelan si la arquitectura está preparada para crecer contigo.

Preguntas sobre arquitectura:

• ¿Monolito o microservicios? ¿Cuál es la justificación para este proyecto concreto?
• ¿La base de datos soporta particionado horizontal? ¿Qué motor usáis y por qué?
• ¿Cómo gestionáis los backups? ¿Cuál es el RPO (punto de recuperación) y el RTO (tiempo de recuperación) garantizados?
• ¿La solución es multi-tenant o instancia dedicada por cliente?

Integraciones: qué exigir por escrito

Para integraciones complejas, consulta la guía de integraciones en software empresarial antes de redactar los requisitos técnicos.

Escalabilidad: pide los límites declarados por escrito (número máximo de usuarios concurrentes, volumen de transacciones por hora) y pregunta si han realizado pruebas de carga con herramientas como Apache JMeter o k6. Un proveedor que no puede responder a esta pregunta con datos no ha probado su solución bajo presión real.

¿Qué cláusulas contractuales evitan que quedes atrapado con un proveedor?

El vendor lock-in no ocurre solo por razones técnicas; ocurre porque el contrato no protege tu acceso al código, los datos y la documentación. Estas cláusulas son negociables y debes incluirlas antes de firmar.

Modelos de propiedad del código:

• Cesión total: el cliente es propietario del código desde el primer commit. Es el modelo más protector y el que debes exigir para desarrollos a medida financiados íntegramente por tu empresa.
• Licencia perpetua: el proveedor retiene la autoría pero te concede uso ilimitado. Aceptable si el proveedor reutiliza componentes propios; exige que el contrato especifique qué partes son propietarias del proveedor.
• Acceso al repositorio: independientemente del modelo de propiedad, exige acceso lector permanente al repositorio (GitHub, GitLab, Bitbucket) desde el primer sprint.

Cláusulas que debes negociar:

• Derecho a copia completa del repositorio en cualquier momento, sin coste adicional.
• Exportación de datos en formatos estándar (CSV, JSON, SQL) con documentación del esquema.
• Entrega de documentación técnica: arquitectura, runbooks de operación, manual de despliegue.
• Garantía de build reproducible: el código entregado debe compilar y desplegarse sin intervención del proveedor.
• Penalización por bloqueo: si el proveedor no entrega el repositorio en el plazo acordado tras la finalización del contrato, se activa una penalización económica proporcional.

Para condiciones de renovación, salida y exportación de datos, revisa también las recomendaciones contractuales para servicios gestionados antes de negociar.

Consejo profesional: Incluye en el contrato una cláusula de depósito en custodia del código fuente (escrow) si el proveedor se resiste a la cesión total. Es una solución intermedia habitual en proyectos de más de 100.000 €.

¿Cómo estructurar una PoC que te dé información real para decidir?

Una prueba de concepto bien diseñada responde a una pregunta concreta de negocio con datos reales. El proceso de selección con periodos de prueba en entornos controlados es la práctica recomendada para reducir el riesgo antes de comprometer el presupuesto completo.

Qué incluir en el brief de PoC:

1. Objetivo medible: «demostrar que el sistema puede procesar 10.000 pedidos diarios con latencia inferior a 2 segundos».
2. Datos reales anonimizados: un subconjunto representativo de tus datos de producción, no datos de ejemplo del proveedor.
3. Duración: entre 2 y 4 semanas. Más tiempo no mejora la calidad de la evaluación; menos tiempo no revela problemas de rendimiento sostenido.
4. Criterios de éxito por escrito: acordados y firmados antes de empezar, no negociados al final.
5. Recursos necesarios: quién de tu equipo participa, qué accesos necesita el proveedor y qué entorno se usa.

Estructura de entregas durante la PoC:

Matriz de comunicación durante el proyecto:

• Reunión de seguimiento semanal (30 minutos): estado, bloqueos y próximos pasos.
• Canal de gestión de incidencias acordado por escrito (correo, Jira, Slack o equivalente).
• Responsable único por cada parte: un interlocutor técnico y uno de negocio en cada lado.
• Escalado definido: si un bloqueo no se resuelve en 48 horas, escala automáticamente al responsable de proyecto de ambas partes.

Para entender el ciclo de vida completo de un proyecto a medida y los roles involucrados, la guía sobre cómo funciona el desarrollo de software personalizado es un buen punto de partida antes de diseñar tu PoC.

¿Qué niveles de prueba debes exigir para protegerte después del lanzamiento?

Las pruebas no son un extra; son la garantía técnica de que lo que recibes funciona como acordaste. Según IBM, las pruebas tempranas reducen el coste y el riesgo porque detectar un defecto en desarrollo cuesta mucho menos que corregirlo en producción.

Niveles de prueba que debes exigir por contrato:

• Pruebas unitarias: verifican que cada función o módulo individual funciona de forma aislada. Exige una cobertura mínima del 70 % del código crítico.
• Pruebas de integración: comprueban que los módulos se comunican correctamente entre sí y con sistemas externos (ERP, CRM, APIs de terceros).
• Pruebas de sistema: validan el comportamiento completo de la aplicación en un entorno equivalente a producción.
• Pruebas de aceptación por usuario (UAT): las realiza tu equipo con casos de uso reales. Son el criterio formal de aceptación antes del pago del hito final.

Criterios de aceptación medibles para la UAT:

• Lista de casos de prueba acordada antes del inicio del desarrollo, no al final.
• Umbral de defectos aceptables: cero defectos críticos, máximo X defectos menores documentados con plan de resolución.
• Plazo de resolución de defectos detectados en UAT: máximo 5 días hábiles para críticos.

Documentos de entrega de pruebas que debes recibir:

• Informe de cobertura de pruebas automatizadas.
• Resultados de regresión tras cada sprint.
• Registro de incidencias con estado de resolución.

¿Qué requisitos de seguridad y cumplimiento son obligatorios en España?

Todo proveedor que trabaje con datos de tu empresa en España debe cumplir el RGPD y la LOPDGDD, supervisados por la AEPD. Estos son los requisitos mínimos que debes verificar, no negociar.

Requisitos técnicos y organizativos mínimos:

• Registro de actividades de tratamiento actualizado y disponible para auditoría.
• Base legal documentada para cada tratamiento de datos personales.
• Control de accesos basado en roles (RBAC) con principio de mínimo privilegio.
• Cifrado en tránsito (TLS 1.2 como mínimo) y en reposo para datos sensibles.
• Procedimiento documentado de notificación de brechas de seguridad en menos de 72 horas (obligatorio por RGPD).

Documentos que debes firmar con el proveedor:

• Acuerdo de tratamiento de datos (DPA) conforme al artículo 28 del RGPD.
• Cláusula de tratamiento de datos en el contrato principal.
• Evidencia de medidas técnicas y organizativas (MTO): política de seguridad, gestión de parches, backups.

Certificaciones relevantes:

• ISO 27001: estándar internacional de gestión de seguridad de la información. Exígela para proyectos con datos sensibles o de alto volumen.
• SOC 2 Tipo II: relevante si el proveedor opera infraestructura en la nube para tu empresa.
• ENS (Esquema Nacional de Seguridad): obligatorio si tu empresa opera en el sector público o trabaja con administraciones.

Consejo profesional: Pide al proveedor su última auditoría de seguridad o prueba de penetración (pentest). Si no tiene ninguna en los últimos 12 meses, ese es un dato que debes incluir en tu evaluación de riesgo.

¿Qué negociar en el SLA y el mantenimiento para no llevarte sorpresas a largo plazo?

El contrato de mantenimiento es donde más empresas pierden dinero después del lanzamiento. Un SLA mal negociado puede dejarte sin soporte en el momento más crítico o con costes de evolutivos que no habías previsto.

Elementos de un SLA que debes definir por escrito:

• Severidades y tiempos de respuesta: incidencia crítica (sistema caído) en menos de 2 horas; alta (funcionalidad principal afectada) en menos de 8 horas; media y baja con plazos acordados.
• Cobertura horaria: horario laboral estándar (L-V, 9:00-18:00) o cobertura extendida 24/7 para sistemas críticos.
• Penalizaciones: descuento en la factura mensual por cada hora de incumplimiento del SLA, con tope máximo acordado.
• Canal de contacto: correo, teléfono, sistema de tickets; el canal debe estar en el contrato, no en un acuerdo verbal.

Modelos de mantenimiento y su coste típico:

Los porcentajes anteriores son orientativos del mercado español; el coste real depende de la complejidad del sistema y del volumen de cambios previstos.

Roadmap y evidencia de inversión en producto: pide al proveedor un roadmap de los próximos 12 meses, aunque sea privado. Un proveedor que no puede mostrar ningún plan de evolución del producto o de la plataforma tecnológica es un riesgo de obsolescencia a medio plazo. Para proyectos con componentes de automatización, la guía sobre automatización en software personalizado ayuda a estimar el impacto de los evolutivos en el TCO.

¿Cómo calcular el coste real del software a medida más allá del precio inicial?

El precio de implementación representa, en muchos proyectos, menos de la mitad del coste total a 3 años. Calcular el TCO completo es la única forma de comparar opciones en igualdad de condiciones.

Partidas del TCO a 3 años:

Modelos de contratación y sus riesgos:

• Precio fijo: previsibilidad presupuestaria, pero el proveedor tiende a reducir alcance ante imprevistos. Exige un proceso de gestión de cambios documentado.
• Tiempo y material: flexibilidad máxima, pero el coste final puede desviarse significativamente. Requiere un seguimiento semanal del consumo de horas.
• Equipo dedicado: adecuado para proyectos largos con requisitos cambiantes; el coste mensual es predecible pero el plazo total no.

Cláusulas contractuales que afectan al coste real:

• Hitos de pago ligados a entregables verificados, no a fechas de calendario.
• Proceso formal de gestión de cambios con aprobación escrita antes de ejecutar cualquier modificación de alcance.
• Derechos de propiedad intelectual sobre el código y los datos: sin cesión explícita, el coste de migración futura puede ser prohibitivo.
• Penalizaciones por retraso en la entrega de hitos críticos, proporcionales al impacto en el negocio.

¿Cómo verificar referencias y qué señales de alerta descartan a un proveedor?

Las referencias son la prueba más fiable de que un proveedor cumple lo que promete. Una llamada de 20 minutos con el responsable técnico de un cliente anterior vale más que cualquier caso de éxito publicado en la web del proveedor.

Preguntas concretas para las referencias:

• ¿El proyecto se entregó en el plazo y presupuesto acordados? Si no, ¿cuánto se desvió y por qué?
• ¿El equipo asignado al inicio fue el mismo que terminó el proyecto?
• ¿Cómo gestionó el proveedor los problemas técnicos graves durante el desarrollo?
• ¿El soporte poslanzamiento ha cumplido los tiempos del SLA?
• ¿Volverías a contratar a este proveedor para un proyecto crítico?

Señales de alerta que descartan a un proveedor:

• Se niega a hacer una PoC con datos reales o solo ofrece demos con datos de ejemplo.
• El soporte técnico solo está disponible en inglés para una empresa española.
• El contrato incluye penalizaciones de salida desproporcionadas o cláusulas de exclusividad no justificadas.
• No puede mostrar ningún proyecto en producción en España con empresa de referencia contactable.
• El equipo de implementación está subcontratado al 100 % y el proveedor no puede identificar a las personas que trabajarán en tu proyecto.
• Los precios no se publican ni se detallan hasta después de varias reuniones.

Pasos para comprobar credenciales:

1. Busca el nombre del proveedor en el Registro Mercantil y verifica que la empresa existe y tiene actividad real.
2. Busca reseñas en Google, LinkedIn y foros especializados en tecnología empresarial en España.
3. Pide acceso a un proyecto en producción (con permiso del cliente) o a un repositorio de muestra.
4. Llama directamente al responsable técnico del cliente de referencia, no al comercial.

Si detectas una señal de alerta durante la negociación: documéntala por escrito, comunícala al proveedor y pide una explicación formal. Si la respuesta no es satisfactoria, descarta al proveedor sin importar cuánto tiempo hayas invertido en el proceso. El coste de cambiar de proveedor durante la negociación es siempre menor que el de cambiar durante el desarrollo.

Lo que los procesos de selección suelen ignorar y acaba costando caro

La mayoría de los procesos de selección de software a medida fallan por el mismo motivo: se evalúa la propuesta técnica con rigor y el contrato con prisa. El resultado es un proveedor bien elegido técnicamente pero con un acuerdo que no protege a la empresa cuando las cosas se complican.

Hay un patrón que se repite: empresas que dedican semanas a comparar arquitecturas y stacks tecnológicos, y luego firman un contrato en 48 horas sin revisar las cláusulas de propiedad del código o las condiciones de salida. Cuando el proyecto se retrasa o el proveedor cambia de equipo, no tienen palancas contractuales para actuar.

El otro error frecuente es tratar la PoC como un trámite en lugar de como una herramienta de decisión real. Una PoC diseñada con datos de ejemplo y criterios vagos no revela nada que no supiera ya el equipo comercial del proveedor. La PoC con datos reales y criterios de éxito escritos antes de empezar es la única que protege tu inversión.

Codentix trabaja con pymes y empresas en crecimiento en España precisamente en estos proyectos: los que tienen requisitos complejos, integraciones con sistemas existentes y necesidad de resultados medibles desde el primer sprint. La experiencia en integraciones complejas y retornos de inversión documentados es lo que diferencia un proveedor que promete de uno que demuestra.

Codentix acompaña cada paso del proceso, desde el análisis hasta el mantenimiento

Muchas empresas llegan al final de este proceso con una checklist completa y una decisión clara, pero sin el socio técnico adecuado para ejecutarla. Codentix cubre cada fase: análisis de requisitos, PoC con datos reales, desarrollo de software a medida, integraciones con sistemas existentes y mantenimiento con SLA documentado.

La diferencia concreta frente a otras opciones es el enfoque en resultados medibles desde el primer sprint: sin promesas genéricas, con hitos de aceptación acordados por escrito y con propiedad del código cedida al cliente desde el inicio. Si tu empresa necesita un análisis inicial antes de comprometer presupuesto, Codentix ofrece una evaluación de requisitos sin coste para proyectos con alcance definido. Contacta con el equipo a través de la página de servicios para solicitar esa primera sesión y recibir una estimación de TCO a 3 años adaptada a tu caso.

Fuentes

Estas fuentes respaldan los criterios y metodologías descritos en esta guía. Úsalas para profundizar en aspectos concretos de tu proceso de evaluación.

• Cómo elegir software empresarial sin fallar — Guía 2026
• Cómo evaluar software antes de adoptarlo y no fallar en el intento

Recomendación

• Software a medida para pymes: cuándo merece la pena — Codentix
• Automatiza antes de contratar: guía práctica para pymes
• Software a medida en integraciones complejas: guía 2026
• Priorizar tareas para automatizar primero: guía para pymes