Software a medida para Administraciones Públicas: cómo contratar desarrollo tecnológico

El software a medida para Administraciones Públicas tiene sentido cuando un ayuntamiento, organismo o entidad pública necesita resolver un proceso que las herramientas estándar no cubren adecuadamente, integrar sistemas de distintos proveedores o construir una aplicación específica sobre una arquitectura ya existente. No debería ser la primera opción por defecto, pero tampoco conviene forzar procesos complejos dentro de soluciones genéricas cuando eso termina generando hojas de cálculo, tareas manuales y desarrollos paralelos.

El reto principal no es únicamente programar una aplicación. Un proyecto público debe combinar análisis funcional, arquitectura, interoperabilidad, seguridad, accesibilidad, gestión de datos, documentación, soporte y una estrategia de salida que permita a la Administración conservar control sobre sus activos digitales.

Dentro de una estrategia de digitalización de la Administración Pública, el desarrollo a medida puede ser especialmente útil para portales internos, cuadros de mando, herramientas de tramitación, automatizaciones, conectores, aplicaciones sectoriales y capas que unifican información procedente de varios sistemas.

Cuándo tiene sentido desarrollar software a medida

El desarrollo específico suele estar justificado cuando existe un proceso con requisitos propios, cuando varias aplicaciones deben coordinarse o cuando una solución comercial obliga a realizar demasiados pasos manuales.

También puede ser adecuado si la entidad necesita explotar datos de diferentes fuentes en una única interfaz, crear un flujo que combine expedientes, documentos y validaciones o proporcionar una herramienta interna adaptada a perfiles concretos.

Antes de decidir conviene realizar una auditoría tecnológica municipal para comprobar si el problema puede resolverse configurando o integrando herramientas existentes.

Cuándo no conviene desarrollar desde cero

Si ya existe una solución pública o de mercado madura que cubre la mayor parte de la necesidad, desarrollar una alternativa completa puede aumentar costes y mantenimiento sin aportar valor suficiente.

Tampoco es recomendable crear software nuevo para compensar un proceso administrativo que todavía no está bien definido. Primero debe revisarse el flujo y eliminar pasos innecesarios.

La guía sobre errores de digitalización en ayuntamientos explica por qué automatizar o programar sobre procesos mal diseñados suele trasladar el problema a otra herramienta.

Definir el problema antes de definir la tecnología

El pliego debería comenzar describiendo qué necesidad se quiere resolver, quiénes son los usuarios, qué datos intervienen y qué resultado debe producir el sistema.

Frases como “crear una plataforma moderna” aportan poco. Es preferible concretar operaciones, volúmenes, roles, integraciones, tiempos de respuesta y resultados esperados.

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

Alcance funcional

El alcance debe describir módulos y funciones desde la perspectiva del usuario. Alta y consulta de registros, generación de informes, gestión de estados, validaciones, aprobaciones, búsquedas, exportaciones o notificaciones son ejemplos habituales.

Cada requisito debería poder asociarse posteriormente a una prueba de aceptación. Si no puede verificarse, probablemente está redactado de forma demasiado ambigua.

También conviene diferenciar funcionalidades obligatorias, evolutivos y posibles fases futuras.

Arquitectura del sistema

La arquitectura debe adaptarse al contexto tecnológico de la entidad. Puede tratarse de una aplicación web, un servicio backend, una capa de integración, una solución cloud o un sistema híbrido.

No es necesario imponer frameworks concretos salvo que exista una razón técnica, pero sí definir requisitos de mantenibilidad, seguridad, portabilidad y compatibilidad.

La categoría de arquitectura digital reúne criterios útiles para analizar estas decisiones.

Integraciones y APIs

En muchos proyectos públicos, el valor principal del software a medida está en conectar sistemas existentes. La aplicación puede necesitar consultar expedientes, validar firmas, recuperar información económica o enviar datos a otro servicio.

La guía sobre integración de sistemas municipales y APIs explica cómo definir autenticación, mapeo de datos, errores, trazabilidad y mantenimiento.

El desarrollo debe evitar duplicar información que ya tiene una fuente oficial.

Interoperabilidad desde el diseño

Un desarrollo aislado puede resolver una necesidad inmediata y convertirse después en un nuevo silo. Por eso debe contemplar exportación, estándares, identificadores y documentación desde el inicio.

La interoperabilidad entre Administraciones Públicas debe formar parte de la arquitectura cuando el sistema intercambia información administrativa.

También conviene pensar en cómo se integrará una futura plataforma que todavía no existe.

Modelo de datos

La base de datos debe reflejar los conceptos reales del proceso y evitar campos ambiguos o duplicados. Cada entidad, relación y estado debería tener un significado claro.

Si el sistema consume información de otras aplicaciones, debe definirse cuál es la fuente maestra y qué datos se almacenan localmente.

El diseño también debe contemplar históricos, trazabilidad y necesidades de conservación.

Expedientes y gestión documental

Cuando la aplicación trabaja con documentos administrativos, el proyecto debe definir metadatos, versiones, firmas y relación con el expediente.

La guía sobre expediente electrónico municipal ayuda a evitar que una nueva aplicación termine funcionando como una simple carpeta de archivos.

Si existe un gestor corporativo, generalmente conviene integrarse con él en lugar de crear un repositorio paralelo.

Firma electrónica

Determinados flujos pueden requerir firma de empleados, autoridades o ciudadanos. El software debe integrarla como parte del proceso y no como una tarea externa.

La guía de firma electrónica en ayuntamientos permite revisar certificados, sellos, validación y conservación.

El sistema debe registrar qué documento se firma y qué evidencia se incorpora al expediente.

Identificación y permisos

Los usuarios deben acceder con mecanismos adecuados al contexto de la aplicación. Los permisos deberían basarse en roles y funciones y aplicar el principio de mínimo privilegio.

No conviene construir reglas de acceso dispersas por la aplicación sin una lógica centralizada y documentada.

También deben quedar registradas las acciones relevantes para facilitar auditoría y soporte.

ENS y seguridad

La seguridad debe incorporarse durante diseño y desarrollo. Esperar a la fase final puede obligar a rehacer arquitectura y componentes.

La guía sobre ENS para ayuntamientos ayuda a contextualizar control de acceso, logs, continuidad, copias y gestión de proveedores.

El pliego debe establecer responsabilidades sobre actualizaciones, vulnerabilidades, secretos y monitorización.

Protección de datos

La aplicación debe limitarse a los datos necesarios para su finalidad. Conviene identificar qué información personal utiliza, dónde se almacena y qué sistemas externos la reciben.

Las copias de desarrollo y pruebas deben estar controladas. No debería utilizarse información real sin necesidad.

El diseño técnico debe coordinarse con las obligaciones jurídicas de la entidad.

Accesibilidad

Las aplicaciones dirigidas a ciudadanía o empleados deben contemplar accesibilidad desde sus componentes básicos. Formularios, tablas, navegación, contraste y mensajes de error necesitan una implementación correcta.

La guía sobre accesibilidad web en ayuntamientos explica cómo convertir estos requisitos en pruebas verificables.

Corregir accesibilidad después de terminar el proyecto suele ser más costoso.

Experiencia de usuario

El software público también necesita una buena experiencia de uso. Una interfaz confusa aumenta formación, errores y resistencia al cambio.

Conviene diseñar alrededor de tareas reales y perfiles de usuario, evitando pantallas que intentan mostrar toda la información disponible al mismo tiempo.

Los prototipos permiten validar flujos antes de desarrollar funcionalidades completas.

Diseño responsive y dispositivos

Según el caso, la aplicación puede necesitar funcionar correctamente en ordenador, tablet o móvil. No todos los módulos requieren la misma adaptación.

El pliego debe indicar escenarios reales de uso para no exigir compatibilidad genérica sin necesidad.

Las pruebas deben realizarse sobre dispositivos y navegadores representativos.

Backend y lógica de negocio

Las reglas críticas deberían estar centralizadas y documentadas. No conviene depender únicamente de validaciones en la interfaz.

El backend debe controlar permisos, consistencia y errores, además de exponer interfaces mantenibles cuando otras aplicaciones necesiten consumir funciones.

Una arquitectura clara facilita incorporar nuevos módulos sin rehacer el sistema.

Automatización dentro del software

Una aplicación a medida puede incorporar reglas para generar tareas, avisar, clasificar información, crear documentos o consultar otros sistemas.

La licitación de automatización de procesos ofrece criterios para definir excepciones, trazabilidad y supervisión.

Automatizar tareas repetitivas suele ser una de las formas más directas de justificar el retorno del desarrollo.

Inteligencia artificial

La IA puede incorporarse a módulos de clasificación, extracción, búsqueda o asistencia, pero debe utilizarse cuando aporte una mejora real.

La inteligencia artificial para servicios públicos requiere métricas, supervisión humana y gobierno de datos.

Conviene separar claramente las reglas deterministas de las respuestas producidas por modelos.

Desarrollo incremental

En proyectos complejos puede ser útil dividir el trabajo en fases. Una primera versión puede resolver el núcleo del proceso y validar la arquitectura antes de incorporar módulos secundarios.

Esto no significa improvisar alcance. Cada fase necesita entregables y criterios de aceptación propios.

El desarrollo incremental reduce riesgo cuando existen dependencias técnicas todavía por validar.

Prototipos y pruebas de concepto

Un prototipo permite validar interfaz y flujo. Una prueba de concepto puede demostrar una integración o tecnología antes de comprometer todo el desarrollo.

Ambas deben tener objetivos concretos y no confundirse con el producto final.

Si forman parte del contrato, debe definirse qué activos se reutilizarán en la fase posterior.

Entornos separados

Desarrollo, pruebas y producción deberían estar separados cuando la criticidad del proyecto lo requiere. Esto reduce el riesgo de afectar datos reales durante una modificación.

El despliegue debe estar documentado y automatizado en la medida razonable.

También conviene definir copias, restauración y procedimiento de reversión.

Control de versiones

El código fuente debe gestionarse en un repositorio con historial de cambios. La entidad necesita conocer dónde está alojado y qué acceso recibirá.

Los cambios deberían asociarse a incidencias o requisitos para mantener trazabilidad del desarrollo.

Este punto es fundamental para la continuidad si cambia el equipo proveedor.

Propiedad del código

El contrato debe definir claramente derechos sobre código, configuraciones, documentación y componentes desarrollados específicamente.

También debe distinguir librerías de terceros y servicios que tienen sus propias licencias.

La Administración necesita suficientes derechos y acceso para evitar quedar bloqueada si decide cambiar de adjudicatario.

Repositorios y cuentas institucionales

Cuando sea posible, dominios, servicios cloud, repositorios y activos críticos deberían quedar bajo control institucional o con un mecanismo claro de transferencia.

No es recomendable que una aplicación pública dependa indefinidamente de cuentas personales del proveedor.

La migración de gestor de expedientes muestra precisamente los problemas que aparecen cuando la salida no se diseñó desde el inicio.

Pruebas unitarias e integración

El proyecto debe combinar pruebas técnicas con validación funcional. No todas las funcionalidades requieren el mismo nivel de automatización, pero las reglas críticas deberían contar con cobertura suficiente.

Las integraciones necesitan pruebas ante respuestas válidas, errores, caídas y datos incompletos.

Las evidencias de prueba deben formar parte del proceso de aceptación.

Pruebas con usuarios

Los responsables funcionales deben validar el sistema antes de producción. Las pruebas deben utilizar escenarios reales y no únicamente datos preparados por el equipo técnico.

Esto permite detectar flujos poco prácticos, permisos incorrectos y excepciones que no aparecieron durante el análisis.

La aceptación debe quedar documentada por módulos o hitos.

Rendimiento

El pliego debe definir volúmenes de referencia cuando existan operaciones críticas. Número de usuarios concurrentes, expedientes, documentos o consultas pueden afectar a la arquitectura.

Las pruebas de carga permiten detectar problemas antes de producción.

Los objetivos deben ser medibles y no utilizar expresiones ambiguas como “respuesta rápida”.

Observabilidad y soporte

La aplicación debería facilitar monitorización de errores, rendimiento e integraciones. El equipo de soporte necesita información suficiente para diagnosticar incidencias.

Los logs deben evitar datos sensibles innecesarios y mantener una política de conservación adecuada.

También debe definirse quién recibe alertas y qué ocurre fuera del horario ordinario si el servicio es crítico.

Mantenimiento correctivo y evolutivo

Después de la puesta en producción habrá correcciones, actualizaciones y nuevas necesidades. El contrato debe diferenciar mantenimiento correctivo de evolutivos.

Si se utiliza una bolsa de horas, deben existir reglas de estimación, aprobación y consumo.

Los SLA deben adaptarse a la criticidad de cada incidencia.

Actualizaciones de dependencias

Frameworks, librerías y servicios externos cambian. El mantenimiento debe contemplar actualizaciones de seguridad y compatibilidad.

Una aplicación abandonada técnicamente puede funcionar durante meses y acumular un riesgo importante.

El adjudicatario debería documentar dependencias principales y política de actualización.

Cómo preparar el pliego

El pliego debe relacionar objetivos, funcionalidades, arquitectura, integraciones, seguridad, pruebas, entregables, soporte y reversibilidad.

La guía sobre pliego técnico para digitalización municipal permite estructurar estos elementos.

Cuanto más verificable sea el requisito, más fácil será comparar ofertas y controlar la ejecución.

Criterios técnicos de adjudicación

Puede valorarse metodología, arquitectura, accesibilidad, seguridad, plan de pruebas, documentación, transferencia de conocimiento y enfoque de integración cuando guarden relación con el objeto.

También puede resultar útil solicitar una propuesta de arquitectura o resolución de un caso concreto sin convertir el procedimiento en una competición de desarrollo gratuito.

La puntuación debe centrarse en calidad ejecutable y no en lenguaje comercial.

Solvencia y perfiles

El equipo puede necesitar análisis funcional, frontend, backend, integración, UX, seguridad y gestión de proyecto según el alcance.

No todos los proyectos requieren todos los perfiles a tiempo completo. La solvencia debe ser proporcional.

La experiencia relevante debería relacionarse con complejidad, integraciones y criticidad, no únicamente con un sector concreto.

Qué puede aportar BlackHold Consulting

BlackHold Consulting trabaja precisamente en proyectos de digitalización y desarrollo de flujos, automatización de procesos, automatización de tareas administrativas e integración y automatización documental.

También dispone de capacidades en desarrollo de procesos complejos, consultoría tecnológica, agentes e integraciones de IA y servicios de automatización. Estas capacidades pueden aplicarse a aplicaciones a medida, integraciones y plataformas internas cuando el procedimiento de contratación pública correspondiente así lo determine.

Checklist para contratar software a medida

Necesidad

¿Está claro por qué una solución existente no cubre el proceso?

Alcance

¿Las funcionalidades pueden verificarse mediante pruebas?

Arquitectura

¿Está definida la relación con sistemas actuales?

Seguridad

¿Se han incluido permisos, logs, copias y mantenimiento?

Accesibilidad

¿La interfaz tendrá criterios comprobables?

Código

¿Está claro quién controla repositorios y derechos?

Pruebas

¿Hay criterios de aceptación y usuarios implicados?

Salida

¿La entidad puede continuar el servicio con otro proveedor?

Preguntas frecuentes

Conclusión

El software a medida puede resolver necesidades que no encajan en productos estándar, pero exige una contratación técnica especialmente bien definida. El valor no está únicamente en el código, sino en construir una solución integrada, segura, accesible y mantenible.

La Administración debe conservar control sobre datos, documentación, repositorios e integraciones y establecer pruebas objetivas antes de aceptar el desarrollo.

Cuando existe una necesidad específica, un equipo capaz de combinar desarrollo, integración, automatización y arquitectura puede convertir procesos fragmentados en herramientas adaptadas a la realidad de la entidad sin crear un nuevo silo tecnológico.

Fotografía: ThisIsEngineering / Pexels.