Desarrollo de software a medida para Administraciones Públicas: cuándo compensa y qué exigir

El desarrollo de software a medida para Administraciones Públicas puede ser la opción adecuada cuando una entidad necesita resolver un proceso que las herramientas estándar no cubren correctamente, integrar varios sistemas o construir una aplicación interna con reglas muy específicas. Pero también puede convertirse en una fuente de sobrecostes y dependencia si se contrata sin una definición clara de alcance, arquitectura, propiedad del código y mantenimiento.

Antes de licitar un desarrollo conviene comparar alternativas: adaptar una solución existente, utilizar un servicio SaaS, automatizar parte del proceso o construir software propio. El objetivo no debería ser “tener una aplicación a medida”, sino resolver una necesidad pública con una solución sostenible, interoperable y mantenible.

Una buena decisión parte de un diagnóstico. La consultoría digital para sector público y la auditoría tecnológica municipal ayudan a determinar si el problema requiere realmente desarrollo o si puede resolverse con configuración e integración.

Cuándo tiene sentido un desarrollo a medida

El software a medida suele tener sentido cuando existen reglas de negocio específicas, procesos transversales, integraciones complejas, necesidades de trazabilidad o requisitos que no encajan en productos estándar. También puede ser útil cuando varias herramientas actuales obligan a duplicar datos o cuando la entidad necesita un portal interno muy ligado a su operativa.

No es recomendable desarrollar desde cero funcionalidades ampliamente resueltas por plataformas consolidadas sin una razón clara. Gestión documental básica, correo, ofimática o autenticación pueden apoyarse en servicios existentes y concentrar el desarrollo en la parte diferencial.

La decisión debe considerar coste total durante varios años, no solo el presupuesto inicial.

Software estándar, SaaS o desarrollo propio

Una solución estándar ofrece rapidez y menor coste inicial, pero puede obligar a adaptar procesos. Un SaaS reduce infraestructura y facilita actualizaciones, aunque introduce dependencia de licencia y proveedor. El desarrollo a medida ofrece más control, pero exige gobierno técnico, mantenimiento y una estrategia de continuidad.

La elección debe comparar cobertura funcional, integraciones, seguridad, coste, portabilidad y capacidad de evolución. También importa saber quién controla los datos y cómo se exportan.

La digitalización de la Administración Pública funciona mejor cuando cada herramienta se selecciona por encaje y no por moda tecnológica.

Definir el problema antes de definir la tecnología

El expediente debería empezar por una descripción del proceso actual: entradas, responsables, decisiones, sistemas, documentos, excepciones y resultados. A partir de ahí pueden definirse objetivos medibles.

Por ejemplo, reducir recaptura de datos, integrar tres aplicaciones, disponer de seguimiento de solicitudes, generar informes automáticos o mejorar tiempos de respuesta. Estos objetivos permiten evaluar si el desarrollo cumple su función.

La asistencia técnica de transformación digital puede ayudar a convertir necesidades funcionales en requisitos contratables.

Requisitos funcionales

Los requisitos funcionales deben describir qué puede hacer el usuario y qué reglas aplica el sistema. Conviene estructurarlos por módulos y casos de uso.

Cada requisito importante debería indicar entradas, validaciones, salida y permisos. En procesos complejos también es útil describir excepciones y estados.

La guía sobre pliego técnico para digitalización explica por qué las especificaciones ambiguas generan ofertas difíciles de comparar.

Requisitos no funcionales

Rendimiento, disponibilidad, seguridad, accesibilidad, mantenibilidad, escalabilidad y portabilidad son tan importantes como las pantallas. Un sistema puede cumplir sus funciones y ser inadecuado para producción si tarda demasiado, no registra actividad o no puede recuperarse ante una incidencia.

Los requisitos deberían ser medibles siempre que sea posible: tiempos máximos de respuesta, usuarios concurrentes, disponibilidad, volumen de datos o frecuencia de copias.

También conviene definir navegadores, dispositivos y necesidades de accesibilidad.

Arquitectura tecnológica

El pliego no necesita imponer cada librería, pero sí puede establecer principios: separación de componentes, APIs documentadas, gestión segura de secretos, registros, entornos diferenciados y capacidad de desplegar versiones.

Una arquitectura modular facilita evolución y reduce el impacto de cambios. También permite sustituir componentes sin reconstruir todo el sistema.

La entidad debe recibir suficiente documentación para entender cómo se estructura la solución.

APIs e interoperabilidad

Muchas aplicaciones públicas deben integrarse con registro, expediente, firma, notificaciones, identidad, sistemas económicos o bases de datos sectoriales. Las APIs deberían considerarse desde el inicio.

La guía sobre interoperabilidad entre Administraciones Públicas permite identificar criterios útiles para evitar silos.

Las interfaces deben documentar autenticación, formatos, errores, límites y versionado. Un desarrollo que solo puede integrarse mediante acciones manuales será más costoso de mantener.

Modelo de datos

El diseño debe identificar entidades, relaciones, fuentes maestras y reglas de calidad. Si el software almacena copias de datos que ya existen en otra plataforma, debe definirse cómo se sincronizan.

También conviene prever exportación desde el inicio. La entidad debería poder obtener sus datos en formatos utilizables sin depender de desarrollos adicionales.

En proyectos documentales, deben considerarse metadatos, firmas y conservación.

Integración con expediente electrónico

Cuando la aplicación genera actuaciones administrativas, no debería crear un circuito paralelo al gestor oficial. Conviene definir cómo se incorporan documentos, referencias y estados al expediente electrónico.

También debe revisarse la firma electrónica si el flujo incluye aprobaciones o resoluciones.

Una integración bien diseñada evita exportaciones y subidas manuales.

Seguridad y Esquema Nacional de Seguridad

La seguridad debe formar parte del diseño. Identidad, permisos, logs, cifrado, copias, gestión de vulnerabilidades y continuidad deben adecuarse al contexto del sistema.

La guía sobre ENS para ayuntamientos ayuda a identificar medidas y responsabilidades que pueden afectar al contrato.

El adjudicatario debe separar sus accesos de los usuarios municipales y mantener trazabilidad de intervenciones técnicas.

Protección de datos

Si la aplicación trata datos personales, el diseño debe aplicar minimización y control de acceso. También debe definirse alojamiento, subencargados, copias y eliminación.

La tecnología no debe recopilar información “por si acaso”. Cada dato debería tener una finalidad vinculada al proceso.

Los entornos de prueba deberían utilizar datos anonimizados o sintéticos cuando sea posible.

Accesibilidad y experiencia de usuario

Las aplicaciones utilizadas por ciudadanía o empleados deben ser comprensibles y operables. Formularios, tablas, mensajes de error y navegación requieren criterios de accesibilidad y usabilidad.

La accesibilidad web municipal puede utilizarse como referencia para interfaces públicas y aplicaciones web.

También conviene realizar pruebas con usuarios reales antes de cerrar el diseño.

Propiedad del código fuente

Uno de los puntos más importantes es definir qué derechos recibe la Administración sobre el código, configuraciones, scripts y desarrollos específicos. No debe quedar implícito.

El contrato puede establecer entrega periódica en un repositorio accesible para la entidad, junto con historial de versiones y documentación. Las condiciones concretas dependerán del modelo y del marco contractual, pero la continuidad debe estar resuelta.

Un repositorio entregado al final sin instrucciones de despliegue tiene un valor limitado.

Dependencias y licencias

El desarrollo puede incorporar librerías, servicios cloud o productos de terceros. La entidad necesita saber qué dependencias existen, qué licencia tienen y qué costes recurrentes generan.

También debe evitarse que componentes esenciales estén contratados exclusivamente en cuentas privadas del proveedor. Dominios, repositorios, servicios cloud y credenciales institucionales deberían mantenerse bajo control adecuado.

El inventario de dependencias debe actualizarse durante el proyecto.

Entornos de desarrollo, pruebas y producción

Un proyecto profesional necesita separar entornos. Los cambios no deberían probarse directamente en producción.

Conviene definir proceso de despliegue, copias, rollback y control de versiones. También quién puede aprobar una versión y cómo se documentan cambios.

Esta disciplina reduce incidencias y facilita soporte posterior.

Pruebas automatizadas y manuales

El contrato puede exigir pruebas unitarias, integración y extremo a extremo para funciones críticas, además de pruebas manuales de aceptación.

Las pruebas deben cubrir permisos, errores, volumen y casos límite, no solo el recorrido ideal. Si existen integraciones externas, también deben simularse fallos y tiempos de espera.

La evidencia de pruebas debería formar parte de los entregables.

Criterios de aceptación

Cada módulo debe tener condiciones objetivas de cierre. Un criterio puede ser completar un caso de uso, alcanzar un rendimiento mínimo, superar una batería de pruebas o demostrar una integración.

Los criterios de aceptación reducen discusiones sobre si una funcionalidad está “terminada”. También permiten asociar hitos de facturación a resultados verificables.

La página de criterios técnicos de adjudicación puede complementar la preparación del procedimiento.

Desarrollo iterativo por fases

Para proyectos complejos puede ser preferible una entrega incremental. Una primera fase cubre el núcleo funcional y las siguientes añaden módulos o integraciones.

Cada iteración debería terminar con software utilizable, documentación actualizada y criterios superados. Esto facilita detectar problemas antes y evita esperar meses para descubrir que el diseño no encaja.

La metodología de alcance y planificación ayuda a estructurar proyectos por entregables.

Migración de datos

Si el software sustituye una aplicación existente, la migración debe tratarse como un subproyecto. Inventario, limpieza, reglas de transformación, piloto y reconciliación deben quedar definidos.

La guía sobre migración de gestor de expedientes muestra una metodología aplicable también a otros sistemas.

La puesta en producción no debería depender de una importación no probada.

Documentación técnica y de usuario

La entidad debería recibir arquitectura, modelo de datos, APIs, instalación, despliegue, configuración, incidencias conocidas y manuales de uso.

La documentación debe actualizarse durante el proyecto. Entregarla solo al final aumenta el riesgo de que quede incompleta.

También conviene incluir un registro de decisiones relevantes.

Formación y transferencia

Los usuarios necesitan formación sobre los procesos que realmente ejecutan. El equipo técnico municipal puede necesitar conocimientos adicionales sobre configuración, monitorización y soporte.

La transferencia de conocimiento reduce dependencia y facilita cambios de adjudicatario.

Las sesiones pueden complementarse con vídeos, manuales y entornos de práctica.

Mantenimiento correctivo y evolutivo

El desarrollo no termina con la puesta en producción. Debe definirse quién corrige errores, cómo se solicitan mejoras y qué tiempos de respuesta existen.

La solución de mantenimiento y soporte ilustra la importancia de SLA, control de cambios y continuidad.

Conviene diferenciar garantía, mantenimiento correctivo, adaptación por cambios externos y evolutivos funcionales.

Evitar vendor lock-in

La dependencia puede aparecer por código no entregado, servicios en cuentas privadas, documentación insuficiente, formatos cerrados o ausencia de APIs.

El contrato debería prever desde el inicio qué necesita la Administración para continuar con otro proveedor: repositorio, datos, documentación, secretos institucionales, infraestructura y soporte de transición.

La reversibilidad debe probarse, no limitarse a una cláusula genérica.

Cómo preparar el expediente de contratación

La redacción de pliegos técnicos debe definir alcance, entregables, arquitectura, datos, pruebas, seguridad, soporte y salida. También es útil una memoria justificativa que explique por qué el desarrollo es necesario frente a otras alternativas.

La solvencia y los perfiles deben ser proporcionales al proyecto. Puede requerirse experiencia en desarrollo, integraciones, datos, seguridad y gestión de proyectos.

La valoración técnica debería centrarse en metodología y capacidad de ejecución demostrable.

Qué puede aportar BlackHold Consulting

BlackHold Consulting trabaja en desarrollo e integración de soluciones digitales vinculadas a digitalización de procesos y flujos, automatización de procesos con IA, automatización de tareas administrativas y consultoría tecnológica.

También desarrolla capacidades de automatización documental, procesos empresariales complejos, agentes e integraciones de IA y servicios de automatización. Estas capacidades pueden aplicarse a proyectos públicos cuando se articulen mediante el procedimiento contractual correspondiente.

Checklist antes de contratar software a medida

Necesidad

El problema está definido y se han comparado alternativas.

Alcance

Módulos, usuarios, integraciones y exclusiones están claros.

Datos

Modelo, fuentes maestras, migración y exportación definidos.

Seguridad

Permisos, logs, continuidad y requisitos ENS considerados.

Código

Propiedad, repositorio, dependencias y licencias definidos.

Pruebas

Casos, rendimiento y criterios de aceptación acordados.

Soporte

Garantía, SLA, mantenimiento y evolutivos separados.

Salida

Reversibilidad y transferencia a otro proveedor previstas.

Preguntas frecuentes

Conclusión

El desarrollo de software a medida puede aportar mucho valor a una Administración Pública cuando resuelve una necesidad real que no encaja en productos existentes. La clave está en definir el problema, diseñar una arquitectura sostenible y contratar con criterios objetivos de calidad, seguridad y continuidad.

El proyecto debe dejar algo más que una aplicación funcionando: código y documentación controlados, datos exportables, integraciones mantenibles, pruebas reproducibles y una estrategia de soporte. Esa base permite evolucionar el sistema sin convertir cada cambio en una dependencia del proveedor inicial.

Cuando el proyecto requiere desarrollo, APIs, automatización o integración con sistemas existentes, un proveedor especializado puede ayudar a convertir la necesidad administrativa en una solución técnica ejecutable y verificable.

Fotografía: cottonbro studio / Pexels.