La respuesta corta

Un pliego técnico para una app móvil falla casi siempre por lo mismo: describe una solución en vez de un resultado. Cuando el pliego dice qué tecnología usar, qué pantallas hacer y cuántas horas dedicar, ha decidido por el licitador y ha renunciado a comparar propuestas de verdad.

La Ley de Contratos del Sector Público empuja justo en la dirección contraria, y da dos herramientas que se usan poco:

  • Consultas preliminares del mercado (artículo 115), para hablar con operadores económicos antes de iniciar el procedimiento y preparar correctamente la licitación.
  • Prescripciones técnicas neutrales (artículo 126), que prohíbe las que favorezcan a un licitador concreto, incluidas referencias a marcas, patentes o procedimientos particulares, y obliga a basarse en características de rendimiento o requisitos funcionales.

Es decir: la ley ya dice que el pliego describa qué tiene que conseguir el sistema, no con qué se construye.

Antes de escribir: la consulta preliminar

Es la herramienta más infrautilizada de la contratación pública de software. Permite preguntar al mercado qué es viable, en qué plazos y con qué riesgos, antes de fijar nada.

Sirve para evitar los tres defectos que arruinan pliegos de app:

  • Plazos incompatibles con el alcance descrito.
  • Requisitos desproporcionados para el riesgo real del sistema.
  • Especificaciones que solo puede cumplir un producto concreto, muchas veces sin que nadie lo pretendiera.

Y no compromete a nada: informa a los operadores de los planes de contratación y sus requisitos, lo que además mejora la calidad de las ofertas que llegan.

Los criterios: calidad, no solo precio

El artículo 145 exige que el diseño de los criterios de adjudicación permita obtener servicios de gran calidad, incorporando aspectos cualitativos, medioambientales, sociales e innovadores vinculados al objeto del contrato, buscando la mejor relación calidad-precio y no el precio más bajo.

Para una app, eso se traduce en criterios que se puedan puntuar sin arbitrariedad:

  • Accesibilidad: nivel comprometido y método de verificación. Es obligación legal, con su declaración y su procedimiento de reclamación — está en accesibilidad en una app pública.
  • Seguridad: medidas conforme a la categoría del sistema en el Esquema Nacional de Seguridad, con las evidencias que se entregarán. La categoría la determina el organismo, y decide el resto — está en el ENS también te aplica a ti.
  • Plan de traspaso: qué se entrega y cómo se garantiza que otro equipo pueda continuar.
  • Metodología y entregables verificables por hito, no por horas.
  • Equipo comprometido, con mecanismo real si cambia. Un currículum en la oferta que desaparece en el mes dos es el problema clásico.

Lo que debe estar en el pliego sí o sí

  1. Titularidad del código y de las cuentas. Repositorio y cuentas de desarrollador a nombre del organismo, con el proveedor invitado. Sin esto, la administración queda cautiva — el detalle de lo que cuesta salir está en transferir una app a otra cuenta.
  2. Categoría ENS del sistema, determinada antes de licitar.
  3. Nivel de accesibilidad y quién audita.
  4. Requisitos de identidad: si hay que identificar, firmar, o ambas — no son lo mismo, y está en integrar Cl@ve.
  5. Versiones mínimas de sistema operativo a soportar, como decisión de cobertura ciudadana.
  6. Mantenimiento evolutivo y correctivo, con su alcance. Una app sin mantenimiento contratado deja de funcionar sola cuando cambian los requisitos de las tiendas.
  7. Traspaso como entregable, no como cortesía final.

Lo que no debería estar

  • El framework. Fijar la tecnología reduce la competencia y traslada al organismo una decisión que debería justificar quien la va a mantener. Si hay un motivo real —un equipo interno que ya trabaja con algo—, se expresa como requisito de mantenibilidad, no como marca.
  • El número de pantallas. Es la peor unidad de medida posible: premia partir pantallas y castiga simplificar.
  • Las horas. Comprar horas es comprar presencia, no resultado.
  • Requisitos copiados de otro pliego sin revisar. Se nota, y generan preguntas que retrasan el procedimiento.

Los lotes: obligatorios, y con una advertencia honesta

El artículo 99 invierte la regla anterior: dividir en lotes es la norma, y hay que justificar en el expediente la no división, para facilitar el acceso de las pymes.

La advertencia técnica, que conviene poner por escrito cuando se justifique: partir app, backend y diseño en lotes distintos traslada el riesgo de integración al organismo. Si se hace, hay que designar quién integra y con qué autoridad, o el resultado son tres adjudicatarios señalándose entre ellos cuando algo falla.

Justificar la no división por integración técnica es legítimo si se argumenta. Lo que no funciona es dividir y no nombrar a un responsable de integración.

Cómo comprobar que el pliego es bueno

Tres pruebas rápidas antes de publicar:

  1. ¿Se puede cumplir con dos tecnologías distintas? Si no, es un pliego dirigido aunque no fuera la intención.
  2. ¿Cada requisito es verificable? Si no se puede comprobar en la entrega, no debería puntuar.
  3. ¿Un licitador podría estimarlo sin llamar? Si le faltan datos críticos —categoría ENS, entornos, integraciones—, las ofertas vendrán con riesgo incorporado, y ese riesgo lo paga el organismo.

Cuando hace falta criterio técnico independiente para redactar o evaluar, es exactamente el trabajo que hacemos como CTO as a Service, y el contexto completo está en apps para el sector público.

Fuente primaria, consultada el 14 de agosto de 2026: Ley 9/2017, de Contratos del Sector Público, artículos 99, 115, 126 y 145.