Cómo redactar el pliego técnico de una app municipal (sin copiar el del vecino)
Un buen pliego técnico de app municipal describe necesidades, no soluciones: qué tiene que resolver la app, no con qué tecnología. Debe incluir alcance funcional, requisitos de accesibilidad y protección de datos, entregables y plazos, propiedad del código y de los datos a favor del ayuntamiento, y el alcance del mantenimiento posterior. Y no puede adjudicarse casi todo por precio: al ser una prestación de carácter intelectual, la calidad debe pesar al menos el 51 %.
En Comboi Labs desarrollamos apps para ayuntamientos y hemos leído bastantes pliegos municipales de aplicaciones móviles. La mayoría tienen el mismo problema: son un copia y pega del pliego de otro ayuntamiento, con el alcance funcional de un municipio que no se parece al tuyo. Esta guía es lo que le contaríamos a un secretario o a un concejal que tiene que redactar el suyo desde cero.
Antes de nada, si tu proyecto está por debajo de los 15.000 € puede que no necesites pliego en absoluto: mira primero hasta dónde llega el contrato menor.
Primero: hay dos pliegos, no uno
Es la confusión más común. Una licitación tiene normalmente dos documentos y conviene no mezclarlos:
- El pliego de cláusulas administrativas particulares (PCAP): procedimiento, solvencia, criterios de adjudicación, precio, plazos de garantía, penalidades. Lo lleva secretaría.
- El pliego de prescripciones técnicas (PPT): qué hay que construir y con qué requisitos. Es el que nos ocupa aquí, y el que suele quedarse corto porque nadie en el ayuntamiento es técnico.
Un PPT flojo no se arregla con un PCAP bueno. Si el alcance no está claro, todas las ofertas serán incomparables entre sí y la ejecución acabará en discusiones sobre qué estaba incluido.
El alcance: describe necesidades, no soluciones
Esta es la regla que más cambia el resultado. Compara:
| Mal | Bien |
|---|---|
| «La app se desarrollará en React Native con backend en Node.js y base de datos PostgreSQL.» | «La app funcionará en iOS y Android con la misma experiencia, y el ayuntamiento podrá publicar avisos sin intervención del proveedor.» |
| «Incluirá un módulo de push de la plataforma X.» | «Permitirá enviar notificaciones segmentadas por tipo de aviso, con registro de envíos consultable.» |
| «Sistema de gestión de incidencias con app nativa y panel web.» | «El vecino podrá reportar una incidencia con foto y ubicación, y consultar su estado hasta la resolución.» |
Hay una razón legal además de la práctica: la Ley de Contratos del Sector Público prohíbe redactar las prescripciones técnicas mencionando una marca, patente, fabricación o procedencia determinada cuando eso favorezca o descarte a determinadas empresas. Solo se admite excepcionalmente, cuando no hay forma de describir el objeto con suficiente precisión, y entonces hay que añadir «o equivalente».
La razón práctica pesa igual: si describes la solución en vez del problema, estás decidiendo la arquitectura del sistema antes de escuchar a nadie que sepa construirlo, y te quedas sin la parte más valiosa de una licitación, que es que varios equipos te propongan cómo resolverlo.
Qué debe entrar en el alcance funcional
Para una app municipal típica, el mínimo razonable es: avisos oficiales, agenda y fiestas, notificaciones push, y opcionalmente incidencias vecinales. El detalle de cada bloque —y las decisiones que se suelen olvidar— está en qué debe incluir una app municipal y, para el módulo de incidencias, en cómo funciona una app de incidencias vecinales.
Lo importante en el pliego es que, para cada bloque, quede claro quién lo va a usar dentro del ayuntamiento y con qué frecuencia. Una funcionalidad sin responsable asignado es una funcionalidad muerta el día después de la inauguración.
Los requisitos legales que no pueden faltar
Aquí es donde más pliegos municipales se quedan cortos, y donde más caro sale después.
- Accesibilidad. Las webs y apps del sector público están sujetas al Real Decreto 1112/2018, que remite al estándar europeo EN 301 549 y, en la práctica, a las pautas WCAG en nivel AA. El pliego debe exigir el cumplimiento y los entregables que lo acreditan: informe de revisión y declaración de accesibilidad publicada. Si no lo pides como entregable, no te lo van a dar.
- Protección de datos. El proveedor será encargado del tratamiento y hace falta el contrato del artículo 28 del RGPD. Define desde el pliego qué datos se tratan, dónde se alojan y qué pasa con ellos al terminar el contrato.
- Seguridad. Los sistemas de información del sector público están dentro del Esquema Nacional de Seguridad. Conviene que el pliego diga expresamente qué categoría aplica y qué se le exige al proveedor, en vez de dejarlo en un «cumplirá la normativa vigente» que no obliga a nada concreto.
- Idioma. En la Comunitat Valenciana, decidir desde el pliego si la app es bilingüe castellano/valencià, y quién aporta y mantiene las traducciones. Añadirlo después cuesta bastante más.
La cláusula que más dinero ahorra: propiedad del código
Si tu pliego no dice de quién es el código, el ayuntamiento se queda atado al proveedor para cualquier cambio futuro. Es la forma más silenciosa de gastar dinero en software público: no en la factura inicial, sino en los cinco años siguientes, cuando cambiar un color en la pantalla de inicio requiere un presupuesto porque nadie más puede tocar el sistema.
«La propiedad intelectual de los desarrollos realizados a medida para este contrato corresponde al Ayuntamiento. A la finalización del contrato, el adjudicatario entregará el código fuente documentado, los scripts de despliegue, la documentación técnica y las credenciales de las cuentas de desarrollador de App Store y Google Play, así como una exportación completa de los datos en formato reutilizable.»
Tres detalles que marcan la diferencia y que casi nadie escribe:
- Las cuentas de las tiendas a nombre del ayuntamiento, no del proveedor. Recuperar una app publicada bajo la cuenta de desarrollador de una empresa que ya no te atiende es un trámite doloroso.
- La exportación de datos en formato reutilizable, no «acceso a consulta». Los datos de los vecinos son del ayuntamiento.
- Distinguir el desarrollo a medida del software de terceros. Si la solución incorpora componentes de terceros o software libre, sus licencias siguen siendo las suyas: la cláusula aplica a lo que se construye para ti, y conviene que el pliego pida la lista de componentes usados y sus licencias.
Criterios de adjudicación: por qué no puedes ir al más barato
Los criterios van en el pliego administrativo, pero se diseñan a la vez que el técnico, así que conviene saberlo antes de empezar: el desarrollo de software a medida se considera normalmente una prestación de carácter intelectual. Y eso tiene dos consecuencias directas.
- Los criterios de calidad deben representar al menos el 51 % de la puntuación. Un pliego que puntúe el 80 % por precio no solo dará un mal resultado: es jurídicamente discutible.
- No puedes usar el procedimiento abierto simplificado abreviado —el «supersimplificado», el de servicios por debajo de 60.000 €—, porque está expresamente excluido para prestaciones de carácter intelectual.
Lejos de ser un estorbo, esto protege al ayuntamiento: es lo que evita acabar adjudicando a la oferta más barata una app que después nadie mantiene. Criterios que sí discriminan bien en software:
- Plan de mantenimiento y soporte: tiempos de respuesta comprometidos, canal, y qué pasa cuando una tienda de aplicaciones cambia sus requisitos y hay que republicar.
- Metodología y entregas intermedias: si el ayuntamiento va a ver algo funcionando antes del final, y cada cuánto.
- Experiencia acreditada en proyectos municipales, con referencias verificables.
- Formación y traspaso al personal que va a gestionar los avisos día a día.
Un aviso honesto: cuidado con los criterios de experiencia demasiado específicos («haber desarrollado tres apps para municipios de entre 8.000 y 12.000 habitantes de la provincia»). Eso ya no es un criterio de calidad, es un pliego escrito a medida de alguien, y es recurrible.
Mantenimiento y garantía: decídelo ahora, no en doce meses
Una app no se termina el día que se publica. Los sistemas operativos cambian, las tiendas actualizan sus requisitos y hay que republicar periódicamente aunque no toques ni una línea de código. El pliego debe dejar claro qué entra en garantía y qué entra en mantenimiento: corregir un fallo de algo que se entregó mal es garantía; adaptar la app a una nueva versión de iOS dos años después es mantenimiento, y se paga.
Cuantificarlo también es tarea del pliego. Los rangos reales, tanto de desarrollo como de soporte anual, están en cuánto cuesta una app para un ayuntamiento. Y si la financiación va a venir de una convocatoria, conviene mirar antes los plazos en subvenciones de digitalización para ayuntamientos, porque condicionan el calendario de la licitación.
Los cinco errores que más vemos
- Copiar el pliego de otro ayuntamiento. Arrastras su alcance, su población y a veces requisitos escritos a medida del proveedor que ya trabajaba allí.
- No decir nada sobre propiedad del código. El silencio siempre juega a favor del proveedor.
- Pedir «todas las funcionalidades» por si acaso. Encarece la oferta y llena la app de pantallas que nadie abre. Mejor un alcance pequeño bien hecho y ampliable.
- Olvidar la accesibilidad como entregable. Exigir cumplimiento sin pedir el informe y la declaración equivale a no exigir nada.
- No definir quién gestiona la app dentro del ayuntamiento. Es la causa número uno de apps municipales abandonadas seis meses después de la foto de la presentación.
Cómo lo planteamos nosotros
Construimos la app oficial del Ayuntamiento de Benissa, así que hemos estado al otro lado del pliego y sabemos qué preguntas quedan sin responder cuando llega el momento de ejecutar. Si tu ayuntamiento está preparando una licitación, te ayudamos a definir los requisitos técnicos sin compromiso y sin pedir exclusividad: preferimos que el pliego esté bien escrito y competir en igualdad a que salga uno ambiguo que acabe en un proyecto imposible de ejecutar, sea nuestro o de otro.
Un pliego neutro y bien redactado también te conviene a ti: es lo que hace que las ofertas sean comparables.
Nota: esto es una guía práctica escrita por un estudio de desarrollo, no asesoramiento jurídico. Los datos legales están comprobados a fecha de agosto de 2026 (LCSP y normativa de accesibilidad y protección de datos del sector público). Antes de aprobar un pliego, contrástalo con la secretaría de tu ayuntamiento y con vuestro delegado de protección de datos.
Preguntas frecuentes
?¿Qué debe incluir el pliego técnico de una app municipal?+
Alcance funcional descrito por necesidades y no por soluciones, requisitos de accesibilidad y protección de datos, requisitos de publicación en las tiendas, entregables y plazos, propiedad del código y de los datos, y alcance del mantenimiento. Los criterios de adjudicación y el precio van en el pliego administrativo.
?¿Se puede nombrar una marca o tecnología concreta en el pliego?+
Por regla general no: la LCSP prohíbe redactar las prescripciones técnicas mencionando marca, patente o procedencia determinada cuando favorezca o descarte a determinadas empresas. Solo excepcionalmente, cuando no hay otra forma de describir el objeto, y añadiendo «o equivalente».
?¿Puede adjudicarse una app municipal solo por precio?+
No es recomendable y normalmente tampoco es posible: el desarrollo a medida suele ser una prestación de carácter intelectual, y en esos contratos los criterios de calidad deben representar al menos el 51 % de la puntuación.
?¿De quién es el código fuente de una app municipal?+
De quien lo diga el pliego. Si no dice nada, el ayuntamiento se arriesga a quedar atado al proveedor. Lo recomendable es que la propiedad del desarrollo a medida y la titularidad de los datos sean del ayuntamiento, con entrega del código documentado y de las credenciales de las cuentas de desarrollador.
?¿Es buena idea copiar el pliego de otro ayuntamiento?+
Como referencia de estructura sí, como contenido no. Arrastras el alcance de otro municipio y a veces requisitos escritos a medida de su proveedor. Lo habitual es acabar pagando funcionalidades que nadie usa y echando en falta lo que de verdad se necesitaba.