Ir al contenido principal
FromNine
Menú

Ingeniería

Desarrollo de software empresarial a medida y de productos SaaS, pensado para durar

Desarrollamos productos SaaS, portales para la ciudadanía y para empleados y aplicaciones de negocio críticas que son accesibles, seguras por defecto y mantenibles por sus propios equipos mucho después de su lanzamiento.

Para empresas y organismos en España que necesitan software a medida que siga funcionando mientras cambian el negocio y la normativa.

Hablemos de su proyectoConozca nuestro enfoque
Software empresarial y SaaS: capas de capacidadCuatro capas superpuestas en profundidad. De arriba abajo: la interfaz accesible que utilizan las personas, los módulos de dominio que contienen las reglas, los servicios de plataforma para la multitenencia y la identidad y, por debajo, el pipeline de entrega segura.01Interfaces accesibles02Módulos de dominio y reglas03Multitenencia, identidad, datos04Pipeline de entrega segura
  1. 01Diseño guiado por el dominio para trabajo cargado de reglas, como la tramitación de expedientes
  2. 02Accesibilidad conforme a EN 301 549 y WCAG 2.2 AA desde el primer sprint
  3. 03Documentación y registros de decisiones que sus equipos pueden asumir

01 Problemas

Lo que oímos antes de una reconstrucción

  1. 01

    Cada cambio tarda un trimestre

    La aplicación funciona, pero nadie se atreve a tocar el núcleo. Los cambios pequeños exigen grandes pruebas de regresión y una ventana de despliegue.

  2. 02

    El portal deja fuera a las personas a las que debe servir

    No funciona con un lector de pantalla, en la segunda lengua oficial ni en el móvil. Las quejas llegan antes que la auditoría de accesibilidad.

  3. 03

    El cambio de un cliente rompe el de otro

    El producto SaaS creció a base de personalizaciones por cliente. Ahora cada versión es una negociación y algunos clientes se han quedado anclados en versiones antiguas.

  4. 04

    El conocimiento se fue con el proveedor

    Las decisiones nunca se pusieron por escrito. El equipo que lo construyó ya no está, y el código es la única documentación.

  5. 05

    Clientes y reguladores empiezan a preguntar por la seguridad

    Contratación pide una SBOM, un proceso de gestión de vulnerabilidades y evidencias para el Reglamento de Ciberresiliencia. Nadie las tiene preparadas.

02 Qué entregamos

Qué entregamos

  1. 01 Ingeniería de productos SaaS

    Productos diseñados para dar servicio a muchos clientes desde una única base de código: el modelo de multitenencia adecuado, configuración en lugar de personalización y versiones que llegan a todos los clientes.

    Qué hacemos

    • Elección del modelo de multitenencia: compartido, agrupado o aislado por cliente
    • Estrategia de configuración y de feature flags
    • Integración de la medición del consumo y la facturación
    • Ciclos de versiones con despliegue escalonado por cliente

    Qué recibe

    • Diseño de multitenencia y aislamiento
    • Modelo de configuración con salvaguardas
    • Proceso de versiones con reversión por cliente

  2. 02 Diseño del dominio para reglas complejas

    Diseño guiado por el dominio cuando las reglas son el producto: tramitación de expedientes, requisitos de acceso a prestaciones, cálculos muy condicionados por la normativa. Elegimos con honestidad entre un monolito modular y los microservicios, y casi siempre empezamos por lo primero.

    Qué hacemos

    • Event storming con expertos del dominio
    • Contextos delimitados y fronteras entre módulos
    • Reglas explícitas y verificables mediante pruebas
    • Registros de decisiones de arquitectura para las grandes elecciones

    Qué recibe

    • Modelo de dominio y mapa de contextos
    • Base de código modular con fronteras verificadas automáticamente
    • Especificaciones ejecutables de las reglas clave

  3. 03 Portales para la ciudadanía y para empleados

    Interfaces construidas sobre un sistema de diseño, accesibles por defecto y multilingües desde la primera versión. En España eso puede significar el castellano y las lenguas cooficiales; en otros países, las lenguas que realmente hablan sus usuarios.

    Qué hacemos

    • Sistema de diseño con componentes accesibles
    • Diseño de contenidos en lenguaje claro
    • Pruebas con tecnologías de apoyo y usuarios reales
    • Flujo de localización para cada idioma

    Qué recibe

    • Portal sobre un sistema de diseño reutilizable
    • Informe de conformidad en accesibilidad
    • Flujo de contenidos y traducción

  4. 04 Ingeniería de calidad y desarrollo seguro

    Automatización de pruebas en los niveles adecuados, pruebas de contrato entre servicios, pruebas de rendimiento antes del lanzamiento y un ciclo de desarrollo seguro basado en OWASP ASVS, SBOM y controles de la cadena de suministro.

    Qué hacemos

    • Estrategia y automatización de pruebas
    • Pruebas de contrato y de rendimiento
    • Modelado de amenazas y verificación ASVS
    • Generación de SBOM y política de dependencias

    Qué recibe

    • Baterías de pruebas automatizadas en el pipeline
    • Informe de verificación de seguridad
    • Proceso de gestión de vulnerabilidades preparado para el Reglamento de Ciberresiliencia

  5. 05 Modernización incremental

    Sustituir una aplicación heredada capacidad a capacidad, tras una fachada de enrutamiento, mientras el negocio sigue funcionando. Consulte también modernización de sistemas heredados.

    Qué hacemos

    • Mapa de capacidades de la aplicación existente
    • Enrutamiento según el patrón strangler fig y encapsulado mediante API
    • Migración de datos con informes de conciliación
    • Ejecuciones en paralelo para los cálculos críticos

    Qué recibe

    • Secuencia de modernización con hitos de negocio
    • Fachada y nuevos módulos en producción
    • Datos conciliados en cada transición

  6. 06 Mantenibilidad y traspaso

    Software del que sus equipos pueden hacerse cargo: código legible, registros de decisiones, runbooks y un plan de traspaso acordado al principio, no descubierto al final.

    Qué hacemos

    • Trabajo en pareja con sus desarrolladores durante la construcción
    • Registros de decisiones de arquitectura guardados junto al código
    • Runbooks operativos y guías de guardia
    • Hitos de transferencia de conocimiento

    Qué recibe

    • Plan de traspaso con criterios de aceptación
    • Documentación en sus propios repositorios
    • Equipo interno formado

03 Arquitectura

Una arquitectura de referencia ilustrativa

Una forma habitual para una aplicación de negocio que sustituye a otra anterior: un front-end accesible, una fachada de enrutamiento que envía cada capacidad al sistema antiguo o al nuevo, una capa de API con contratos claros y un núcleo modular organizado en torno al dominio.

La multitenencia y la configuración son servicios de plataforma explícitos, no condiciones dispersas por el código. Por debajo, cada compilación ejecuta pruebas y controles de seguridad y genera una SBOM.

Capas del diagrama

Personas
Ciudadanía, clientes y empleados, desde cualquier dispositivo y con tecnologías de apoyo.
Modernización
La fachada de enrutamiento, la aplicación existente y la migración de datos con conciliación.
Plataforma
Capa de API, identidad, núcleo modular, multitenencia y configuración, datos operativos.
Entrega segura
Pruebas de contrato y de rendimiento, controles ASVS y una SBOM en cada compilación.
Ejemplo ilustrativo

  1. Personas

    • Ciudadanía, clientes, empleados
    • Front-end accesible

  2. Modernización incremental

    • Fachada de enrutamiento
    • Aplicación existente
    • Migración con conciliación

  3. Plataforma

    • Capa de API y contratos
    • Identidad y roles
    • Núcleo modular: entrada, expedientes, facturación
    • Multitenencia, configuración, feature flags
    • Almacenes de datos operativos

  4. Entrega segura

    • Pruebas de contrato y de rendimiento, controles ASVS, SBOM en cada compilación
Núcleo modular tras una fachada de enrutamiento

Arquitectura ilustrativa, no corresponde a ningún sistema de cliente.

Leer el diagrama como texto

El recorrido principal va de las personas a un front-end accesible y, a través de una fachada de enrutamiento y una capa de API, a un núcleo modular organizado en contextos delimitados.

La fachada también envía algunas capacidades a la aplicación existente, que se retira paso a paso. Sus datos pasan, mediante una migración con conciliación, a los almacenes de datos operativos.

La identidad da servicio a la capa de API. Los servicios de multitenencia y configuración se sitúan bajo el núcleo. Una franja de entrega segura en la parte inferior abarca pruebas de contrato, pruebas de rendimiento, verificación de seguridad y SBOM.

04 Consideraciones y límites

Consideraciones de ingeniería y límites

  • Primero, un monolito modular

    Cómo lo abordamos

    Empezamos con módulos bien definidos en una única unidad desplegable y solo separamos servicios cuando lo exigen la escala, el ritmo de versiones o la responsabilidad de los equipos.

    Límites y dependencias

    Los microservicios resuelven problemas organizativos tanto como técnicos. Sin equipos que se hagan cargo de ellos, añaden coste y nuevas formas de fallar.

  • La accesibilidad es trabajo de ingeniería

    Cómo lo abordamos

    Componentes accesibles, controles automáticos en el pipeline y pruebas manuales con tecnologías de apoyo antes de cada versión importante.

    Límites y dependencias

    Las herramientas automáticas solo detectan una parte de los problemas. La conformidad plena exige auditorías manuales y, idealmente, pruebas con personas con discapacidad.

    Los contenidos y documentos que añaden los editores tras el lanzamiento deben cumplir el mismo estándar. Formamos a los editores, pero no controlamos lo que publican.

  • La modernización dura lo que duran los datos

    Cómo lo abordamos

    La migración de datos se planifica por capacidad, se ensaya y se concilia, con la aprobación del negocio en cada transición.

    Límites y dependencias

    La calidad de los datos heredados suele marcar el ritmo. Depurarlos es tanto una tarea de negocio como técnica.

  • Normativa para productos de software

    Cómo lo abordamos

    Las SBOM, la gestión de vulnerabilidades y la configuración segura por defecto forman parte de nuestro pipeline estándar, que prepara los productos para el Reglamento de Ciberresiliencia.

    Límites y dependencias

    Si el Reglamento se aplica a su producto, y de qué manera, es una cuestión jurídica. Nosotros aportamos las evidencias técnicas; sus asesores legales hacen la valoración.

05 Cómo trabajamos

Cómo trabajamos

Ciclos cortos, usuarios reales desde el principio y el traspaso planificado desde la primera semana.

  1. 01

    Cartografiar el dominio

    Event storming con las personas que conocen las reglas y un mapa de capacidades de lo que existe hoy.

    ResultadoMapa de contextos y primeros registros de decisiones

  2. 02

    Entregar una primera porción

    Una capacidad de extremo a extremo, a través de la fachada, en producción con usuarios reales.

    ResultadoPorción operativa en producción

  3. 03

    Crecer capacidad a capacidad

    Cada versión traslada una capacidad, sus datos y sus usuarios, con la conciliación y la reversión preparadas.

    ResultadoPlan de versiones por capacidad

  4. 04

    Traspasar

    Sus desarrolladores trabajan en pareja con los nuestros, asumen las guardias y se hacen cargo de la hoja de ruta cuando se cumplen los criterios de traspaso.

    ResultadoTraspaso aceptado

06 Control humano

Dónde mantienen el control las personas

En el software de negocio, tener el control significa saber quién cambió qué, quién lo aprobó y cómo deshacerlo.

  • Los product owners deciden el alcance

    Su product owner fija las prioridades y acepta cada incremento. Nosotros asesoramos; ellos deciden.

  • La configuración tiene un responsable

    Los parámetros de cada cliente y los feature flags se modifican mediante un proceso auditado, por los roles que usted asigna.

  • Las transiciones se aprueban

    Cada paso del sistema antiguo al nuevo lo aprueba el negocio, con una reversión ensayada.

  • Las decisiones quedan por escrito

    Los registros de decisiones de arquitectura muestran qué se eligió, quién lo hizo y por qué, para que los equipos futuros puedan revisarlo con conocimiento de causa.

07 Tecnologías

Tecnologías con las que trabajamos

Back-end
  • Java y Kotlin
  • .NET
  • TypeScript y Node.js
  • Python
Front-end
  • React y Next.js
  • Angular
  • Sistemas de diseño con componentes accesibles
  • Aplicaciones móviles nativas y multiplataforma
Datos
  • PostgreSQL
  • SQL Server y Oracle (entornos existentes)
  • Streaming de eventos
  • Motores de búsqueda
Calidad y seguridad
  • Playwright y pruebas de contrato
  • Pruebas de carga y de rendimiento
  • SAST, DAST y análisis de dependencias
  • SBOM en CycloneDX o SPDX

La mención de una tecnología refleja nuestra experiencia de ingeniería. No implica ninguna asociación con su fabricante ni su respaldo.

08 Ejemplo

Un ejemplo ilustrativo

Ejemplo ilustrativo

Un área de clientes accesible para una empresa de aguas

01Situación
Una empresa de abastecimiento de agua debe adaptar su área de clientes a los requisitos de accesibilidad de la Ley 11/2023, y la aplicación actual no admite cambios sin poner en riesgo la facturación.
02Qué construiríamos
Un área de clientes reconstruida por fases sobre componentes accesibles reutilizables, conectada a la facturación existente mediante API estables mientras el sistema antiguo sigue en servicio.
03Dónde deciden las personas
Cada versión supera una auditoría de accesibilidad según la norma UNE-EN 301549 antes de publicarse; el equipo de atención al cliente aprueba los cambios en los flujos.
04Qué mediríamos
Conformidad de accesibilidad por versión, porcentaje de gestiones completadas en línea e incidencias tras cada publicación.

09 Por sectores

En su sector

  • Sector público y Administración

    Gestión de expedientes y portales para la ciudadanía que cumplen la normativa de accesibilidad, funcionan en todas las lenguas oficiales y se conectan a las plataformas nacionales de intercambio de datos.

  • Servicios financieros

    Portales de clientes y aplicaciones de back office con pistas de auditoría sólidas y procesos de versiones que satisfacen el control de cambios.

  • Industria y fabricación

    Configuradores, portales de servicio y productos SaaS para fabricantes de equipos, conectados al ERP y al servicio técnico de campo.

España

Software para el mercado español

El software que se vende o se presta en España debe cumplir hoy varias capas de requisitos. La Ley 11/2023 traslada la Acta Europea de Accesibilidad a los productos y servicios digitales; los sistemas de facturación deben cumplir Verifactu; y, desde septiembre de 2026, el Reglamento de Ciberresiliencia obliga a los fabricantes a notificar las vulnerabilidades explotadas activamente. Si su cliente es la Administración, el Esquema Nacional de Seguridad entra además en el pliego.

Integramos estos requisitos en la arquitectura y en las pruebas automáticas desde el primer incremento.

Preguntas sobre software empresarial y SaaS

¿Conviene desarrollar a medida o configurar una plataforma?

Configure una plataforma cuando su proceso se acerque al estándar, y desarrolle a medida cuando el proceso sea lo que le diferencia o cuando ninguna plataforma se ajuste a las reglas. Trabajamos con Salesforce, SAP y Odoo además de con código a medida, así que no tenemos motivo para empujar hacia una sola respuesta. Nuestro trabajo de arquitectura y consultoría hace explícita esta elección.

¿Pueden garantizar que nuestro portal será accesible?

Desarrollamos conforme a EN 301 549 y WCAG 2.2 AA, realizamos pruebas automáticas y manuales y entregamos un informe de conformidad con los problemas conocidos. No prometemos cero incidencias; prometemos encontrarlas, informar de ellas y corregir las que entran en nuestro alcance.

¿Pueden modernizar sin una migración de golpe?

Sí, y es lo que recomendamos. Una fachada de enrutamiento permite trasladar una capacidad cada vez mientras la aplicación existente sigue funcionando, con los datos conciliados en cada paso.

¿Puede nuestro propio equipo hacerse cargo del software?

Es el plan por defecto. Los criterios de traspaso se acuerdan al principio, sus desarrolladores trabajan en pareja con los nuestros durante la construcción y los registros de decisiones y los runbooks residen en sus repositorios.

¿Qué implica el Reglamento de Ciberresiliencia para nuestro producto?

Si comercializa en la UE productos con elementos digitales, incluido software, el Reglamento puede conllevar obligaciones en materia de diseño seguro, gestión de vulnerabilidades y documentación. Nosotros generamos las evidencias técnicas: SBOM, un proceso de gestión de vulnerabilidades y configuración segura por defecto. La valoración jurídica corresponde a sus asesores legales.

Cuéntenos qué debe seguir funcionando mientras cambia

Partimos de su producto o sistema actual y le proponemos una primera fase con un alcance y un presupuesto claros.

Hablemos de su proyectoConozca nuestro enfoque