Servicios que la ciudadanía puede usar de verdad
La mayoría de los servicios digitales públicos se rehacen cada seis años y siguen saliendo inaccesibles. Nosotros los construimos una sola vez, bien. WCAG 2.2 AA desde el primer commit, audit log desde el primer día, documentación lista para las inspecciones.
Los problemas que más escuchamos
La auditoría de accesibilidad llega al final, cuando arreglar cuesta diez veces más
Dos semanas antes del lanzamiento aparece el informe, trae 80 hallazgos y la mitad pide un rediseño que nadie había presupuestado. WCAG 2.2 AA funciona como disciplina de trabajo, no como sello final.
Un servicio pensado para Internet Explorer en 2014 que hoy se rompe en el móvil
El pliego pedía soporte a IE11, el contrato es de 2019, el formulario falla en un Android de cuatro años. La línea base equivocada bloquea el resultado desde el primer día.
Licitaciones que dejan fuera el stack moderno
Pliego a cinco años, alcance rígido, ningún margen para que la arquitectura evolucione. El proveedor que gana promete lo que luego no entrega, los licitadores serios se quedan fuera. En los dos casos paga el ciudadano.
Identidad digital tratada como una casilla que marcar
Cl@ve, certificado digital, eIDAS, esquemas autonómicos: cada uno integrado con su propio flujo, su propia sesión y su propio audit log. La experiencia para quien entra al servicio nunca se recupera. La identidad es la puerta de entrada, merece el mismo cuidado que el resto del edificio.
Multilenguaje añadido al final, mal hecho
El servicio nace en castellano, las lenguas cooficiales pasan por una traducción automática, la declaración de accesibilidad sale en el idioma equivocado. El plural de los idiomas es una decisión de arquitectura, no una tabla de cadenas que se rellena al final.
Documentación de cumplimiento escrita aparte del código
La política de privacidad dice una cosa, el registro de actividades dice otra, la declaración de accesibilidad se generó hace seis meses con una plantilla. El día de la inspección tres documentos no coinciden.
Bloqueo de proveedor disfrazado de "servicio gestionado"
Acaba el contrato, el código vive en una plataforma propietaria y la licitación siguiente arranca desde cero. El dinero público paga dos veces el mismo servicio.
Qué entregamos en este vertical
WCAG 2.2 AA desde el primer commit
Accesibilidad lista para auditoría, no un sprint de remediación. La declaración de accesibilidad nace del código real, actualizada en cada release.
Datos alojados en la UE por arquitectura
Hosting, base de datos, almacenamiento y colas: todo en regiones UE, vinculado por contrato. Sin fallback en Estados Unidos.
Identidad digital en una sola sesión
Cl@ve, certificado digital, nodo eIDAS y esquemas autonómicos integrados en una sola capa de autenticación. Misma experiencia para cualquiera que entre, misma trazabilidad para quien audita.
Multilenguaje como decisión de arquitectura
Castellano y lenguas cooficiales con routing en la URL, hreflang correcto, plurales bien tratados y declaración de accesibilidad localizada para cada idioma.
Audit log en cada acción privilegiada
Quién cambió qué, cuándo, desde qué IP y con qué motivo. Exportable, consultable, firmado.
Flujo documental con firma electrónica cualificada eIDAS
Generación de PDF, firma electrónica cualificada conforme a eIDAS, archivado con los plazos de conservación que aplica tu servicio por normativa.
Código abierto donde importa
Stack estándar que el siguiente equipo puede leer. Sin cláusulas de bloqueo, sin licencias por puesto, sin sorpresas en la renovación.
Performance que va al pliego
Objetivos Core Web Vitals dentro del contrato, verificados bajo carga, reportados en cada release. INP por debajo de 200 ms, LCP por debajo de 2,5 segundos, medidos en los dispositivos reales de la ciudadanía.
APIs para la interoperabilidad (compatibles ENI)
Especificación OpenAPI, versionada, rate-limited, documentada. Otras administraciones se integran sin seis meses de mesa técnica.
Documentación lista para la licitación
Memoria técnica, seguridad (ENS), declaración de accesibilidad, registro de actividades, plan de conservación. Generados a partir del código, no de una plantilla.
Front-end de servicio para la ciudadanía
Solicitudes, estado del expediente, subida de documentos, recibos. Funciona en móvil, en los idiomas soportados, sin cuenta cuando la normativa lo permite.
Traspaso que no deja al siguiente equipo en el aire
Design system, documentación, runbooks. La licitación siguiente arranca con materiales listos, no con folio en blanco.
Un stack que aguanta un contrato a cinco años
Cada decisión técnica de aquí abajo nace del hecho de que el ciclo de vida en sector público es largo, los requisitos para la ciudadanía solo crecen y el siguiente equipo que toque el código quizá no seamos nosotros. Elegimos tecnología que aguanta en ese segundo momento, cuando el contrato original termina y otra persona se sienta a leer el código.
Front-end de cara a la ciudadanía y back office de gestión interna viven en un mismo código, construido sobre Next.js App Router. El servicio público se posiciona bien en buscadores, abre rápido al primer clic y quien gestiona los contenidos trabaja desde el mismo sitio donde el back office revisa las solicitudes. Un solo repositorio, un solo despliegue, y la separación entre "la página que ve la ciudadanía" y "el sistema que procesa la solicitud" deja de ser un coste de coordinación.
Los datos del ciudadano quedan aislados a nivel de base de datos, no en el código de la aplicación, y ese es el punto: toda inspección de un servicio público acaba preguntando lo mismo, esto es, cómo se garantiza la separación entre departamentos, entes o grupos sensibles. Con Supabase Postgres y row-level security la respuesta cabe en una pantalla de código, y queda en la documentación técnica que acompaña al servicio. La misma base de datos también gestiona cuentas, archivos y actualizaciones en tiempo real, hospedada en región UE por contrato.
La autenticación pone Cl@ve, certificado digital, nodo eIDAS y esquemas autonómicos en una sola capa de sesión. El ciudadano vive la misma experiencia con DNI electrónico, con identidad bancaria respaldada o con un proveedor eIDAS transfronterizo, y el audit log registra qué proveedor se usó en cada acción. Cuando la auditoría de accesibilidad pregunta cómo un lector de pantalla llega al expediente, la respuesta es el mismo flujo, sin atajos pensados solo para quien ve.
Los documentos que necesitan firma electrónica cualificada pasan por un proveedor compatible con eIDAS, con el PDF firmado guardado junto al expediente y la conservación que aplica a tu servicio. El recibo que recibe el ciudadano nace de la misma plantilla que usa el operador interno, y las dos versiones nunca se separan.
Una infraestructura que no se dispara en coste cuando crece el volumen del servicio: Upstash Redis en el edge gestiona rate limit y protección antiabuso sin levantar un servidor, Cloudflare R2 guarda los adjuntos en región UE sin sorpresas en egress, y todo el stack está tipado con TypeScript de principio a fin. El beneficio es poco lucido pero decisivo: cuando termina el contrato y otro equipo abre el código, el producto no se rompe en silencio y la persona que entra al proyecto se orienta sin visita guiada.
Preguntas que hacen los founders
¿Trabajan con la Plataforma de Contratación del Sector Público y otras licitaciones?
Sí. Hemos trabajado dentro de pliegos de alcance fijo, acuerdos marco y contratos menores. Redactamos la memoria técnica en el formato que la mesa de contratación acepta y delimitamos el alcance para que el contrato tenga una definición de hecho verificable.
WCAG 2.2 AA, Real Decreto 1112/2018, EAA 2025: ¿cómo los gestionan?
WCAG 2.2 AA es el suelo, no el techo. Probamos con tecnología asistiva durante la build, no al final, y la declaración de accesibilidad nace del código real para que nunca se separe de la realidad. El Real Decreto 1112/2018 y el European Accessibility Act 2025 se cubren con la misma disciplina.
¿Los datos se quedan en la UE?
Sí. Hosting, base de datos, almacenamiento de archivos, colas y CDN se configuran todos en regiones UE con proveedores vinculados por contrato. Documentamos el flujo de datos para que la persona responsable de protección de datos pueda firmarlo sin dudas.
¿Cómo integran Cl@ve, certificado digital y eIDAS?
Una sola capa de sesión los cubre todos, con el mismo audit log y la misma experiencia para el ciudadano, sea cual sea el proveedor que elija. La integración ya es un camino conocido, no una sorpresa a mitad de proyecto.
¿Qué pasa al terminar el contrato?
Un traspaso que otro equipo puede recoger. Código fuente en tus repositorios, infraestructura en tus cuentas, documentación nacida del código y no de una plantilla, design system en un paquete versionado. La licitación siguiente arranca con materiales, no con folio en blanco.
¿Soportan lenguas cooficiales?
Sí. Routing, hreflang, copy con plurales coherentes y declaraciones de accesibilidad localizadas para cada idioma forman parte de la build, no son un añadido final. Hemos puesto online servicios multilenguaje desde el primer commit y el mismo patrón sirve para las lenguas reconocidas por el ordenamiento.
¿Hacen migración de sistemas heredados?
Sí. La mayoría de los servicios públicos en los que trabajamos sustituyen algo que ya existe. Tratamos a los usuarios actuales como línea base, no como folio en blanco: los identificadores se mantienen, el historial sigue siendo consultable, el servicio nuevo arranca con paridad de funcionalidades o con un plan de migración documentado si no la tiene.
¿Cómo facturan al sector público?
Factura electrónica conforme al sistema FACe, con código de unidad tramitadora y CIF del organismo. Estamos acostumbrados a órdenes de compra, certificaciones parciales y trazabilidad de pagos prevista por la Ley de Contratos del Sector Público.
Cuéntanos el servicio
Una llamada de scoping, un plan concreto en la primera respuesta, sin teatro de agencia. Respondemos a los pliegos dentro del plazo indicado.