Para equipos del sector público
Un servicio digital público vive durante años: solicitudes de la ciudadanía, actualizaciones de idiomas, auditorías de accesibilidad, y el siguiente equipo recogiendo el trabajo donde terminó el contrato. Construimos el servicio para que aguante todo ese recorrido. La accesibilidad se prueba mientras se escribe el código, y la documentación de cumplimiento nace directamente del código en producción, en lugar de irse separando de la realidad mes tras mes en una carpeta de PDFs.
El informe llega dos semanas antes del lanzamiento, con ochenta hallazgos, y la mitad pide un rediseño que nadie había presupuestado. WCAG 2.2 AA funciona como disciplina de trabajo durante todo el proyecto, en lugar de un sello que se aplica a última hora.
Pliego a cinco años, alcance rígido, ningún margen para que la arquitectura evolucione durante el contrato. El proveedor que gana promete lo que después no entrega, y las empresas serias ni se presentan al concurso. En los dos casos quien paga es la ciudadanía.
Cl@ve, certificado digital, eIDAS, esquemas autonómicos. Cada integración termina como un flujo aparte, con su propia sesión, su propio registro, su propia interfaz. Quien intenta entrar encuentra una puerta distinta cada vez, y la experiencia ya no se recupera después del primer intento.
Termina el contrato, el código vive en una plataforma propietaria, la siguiente licitación arranca desde cero. El dinero público paga dos veces el mismo servicio.
Las pruebas con tecnología asistiva ocurren mientras se escribe el código, y no al final del proyecto. La declaración de accesibilidad nace del código en producción y se refresca con cada release, por eso nunca se separa de la realidad que ve la ciudadanía.
Hosting, base de datos, almacenamiento, colas, CDN: cada componente queda configurado en regiones UE, con el proveedor vinculado por contrato. El flujo de datos vive en un diagrama que la persona responsable de protección de datos firma sin reservas.
Una sola capa de autenticación cubre el DNI electrónico, las identidades bancarias respaldadas, y los proveedores eIDAS transfronterizos. Quien entra se encuentra el mismo flujo con cualquier proveedor, y la administración lee en un mismo registro qué proveedor se usó en cada acción.
Castellano y lenguas cooficiales con routing en la URL, hreflang correcto, plurales bien tratados, y declaración de accesibilidad localizada por idioma. La traducción ocurre dentro de la fase de diseño, y no al final del proyecto.
Quién cambió qué, cuándo, desde qué IP, y con qué motivo. El registro es consultable, exportable, firmado. El día de la inspección, la respuesta ya está lista.
Código fuente en vuestros repositorios, infraestructura en vuestras cuentas, documentación generada desde el código, design system entregado en un paquete versionado. La siguiente licitación arranca con materiales en mano, y no con folio en blanco.
Cada decisión técnica se ancla en un hecho. Un servicio público vive durante años, los requisitos de la ciudadanía solo crecen con el tiempo, y el siguiente equipo en leer el código puede no ser el nuestro. Elegimos el stack pensando en ese segundo momento, cuando el contrato termina y otra persona se sienta a abrir el proyecto.
La parte que ve la ciudadanía y la consola del operador viven dentro de un mismo proyecto Next.js. El servicio se indexa en buscadores, abre rápido al primer clic, y quien gestiona los contenidos trabaja desde el mismo sitio en el que se revisan los expedientes. 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 costar coordinación entre departamentos.
Los datos del ciudadano quedan aislados a nivel de base de datos, y no solo dentro del código de la aplicación. Es el punto en el que se juega cada inspección de un servicio público, porque la pregunta es siempre la misma: cómo se garantiza de verdad la separación entre departamentos, entes o grupos sensibles. Con un Postgres gestionado y una regla que filtra el acceso fila por fila, la respuesta cabe en una pantalla de código, y queda directamente en la documentación técnica que acompaña al servicio. La misma base de datos gestiona cuentas, archivos adjuntos, y actualizaciones en tiempo real, alojada en región UE por contrato.
La autenticación pone Cl@ve, certificado digital, el nodo eIDAS, y los esquemas autonómicos en una sola capa de sesión. Quien entra se encuentra el mismo flujo independientemente del proveedor que elija. El registro de acciones guarda qué proveedor se usó en cada evento, y cuando la auditoría de accesibilidad pregunta cómo llega al formulario una persona que usa lector de pantalla, la respuesta es el mismo flujo que para el resto, sin atajos escritos solo para quien ve.
Los documentos que necesitan firma electrónica cualificada pasan por un proveedor compatible con eIDAS. El PDF firmado queda junto al expediente, con los plazos de conservación que marca la normativa del servicio. El recibo que recibe el ciudadano nace de la misma plantilla que usa el operador interno, y por eso las dos versiones no se separan con el tiempo.
La infraestructura no se dispara en coste cuando el tráfico crece. La protección frente al abuso de uso pasa por una caché distribuida gestionada, ubicada geográficamente cerca de quien envía solicitudes, sin tener que levantar un servidor dedicado. Los archivos adjuntos quedan en un object storage en región UE, sin las sorpresas de coste que la línea "transferencia de datos saliente" lleva en otros proveedores. Todo el código se verifica en tiempo de compilación con TypeScript, un beneficio poco lucido pero decisivo: cuando termina el contrato y otro equipo abre el proyecto, los fallos salen antes del lanzamiento, y la persona que entra se orienta sin visita guiada.
Sí. Hemos trabajado dentro de pliegos de alcance fijo, acuerdos marco, y contratos menores. Redactamos la memoria técnica en el formato que acepta la mesa de contratación, y delimitamos el alcance para que el contrato lleve una definición de hecho verificable.
WCAG 2.2 AA es la base mínima de la que se parte. La prueba con tecnología asistiva ocurre durante el desarrollo, y no al final. La declaración de accesibilidad nace del código del servicio, y por eso nunca se separa de la realidad. El Real Decreto 1112/2018 y el European Accessibility Act 2025 se cubren con la misma disciplina.
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 lo firme sin reservas.
Un traspaso que otro equipo puede recoger y continuar. Código fuente en vuestros repositorios, infraestructura en vuestras cuentas, documentación generada desde el código, design system en un paquete versionado. La siguiente licitación arranca con materiales en mano, y no con folio en blanco.
Sí. El routing, el hreflang, los plurales bien tratados, y las declaraciones de accesibilidad localizadas por idioma forman parte del desarrollo, y no son un añadido final. Hemos puesto en producción servicios multilenguaje desde el primer release, y el mismo patrón sirve para las lenguas que reconoce el ordenamiento.
Una llamada para enmarcar el proyecto, y un plan concreto en la primera respuesta. Respondemos a los pliegos dentro del plazo que indica la convocatoria.
Founders SaaS, de pre-seed a Series A
Founders fintech que desarrollan neobancos, wallets, lending, pagos
Fabricantes mid-market que desarrollan cockpits operativos
Founders que desarrollan productos cloud para consumer y utility apps