Proyecto propio de Julmen
Lavorial: desarrollo de una plataforma SaaS multiempresa
Lavorial es una plataforma de gestión para negocios que hemos diseñado y desarrollado en Julmen: varias organizaciones en una misma aplicación, con reservas, facturación y módulos según el tipo de negocio. Este caso explica cómo está construida y qué decisiones hay detrás.
¿Qué es Lavorial?
Lavorial es una plataforma SaaS de gestión multiempresa desarrollada por Julmen. Permite que varias organizaciones usen una misma aplicación, cada una con sus propios usuarios, datos y módulos, y reúne reservas, facturación y herramientas de administración para distintos tipos de negocio.
- Tipo
- Plataforma SaaS multiempresa (multi-tenant)
- Desarrollo
- Julmen Digital Solutions: arquitectura, backend, frontend, datos e infraestructura
- Módulos desarrollados
- Administración, facturación, reservas para salón y peluquería, y gimnasio
Es un producto propio, no un encargo de un cliente. Esta página no recoge datos de usuarios, clientes ni cifras de negocio.
El reto
El reto de arquitectura era construir una sola plataforma capaz de servir a varios negocios a la vez sin mezclar sus datos, y que pudiera crecer con módulos nuevos sin rehacerse cada vez.
Eso implica resolver a la vez varios problemas que en una aplicación sencilla no existen: separar con garantías la información de cada organización, gestionar usuarios y permisos por organización, calcular disponibilidad sin dobles reservas, facturar con requisitos fiscales y poder activar o no cada módulo según el negocio.
Un SaaS multiempresa
En una arquitectura multiempresa (multi-tenant), una misma aplicación atiende a muchas organizaciones. Cada una debe ver únicamente sus propios datos, aunque todas compartan el mismo sistema.
- Cada usuario, reserva, factura y configuración pertenece a una organización.
- Los permisos dependen del rol del usuario dentro de su organización.
- Cada organización decide qué módulos tiene activos.
- Los datos se separan lógicamente dentro de una misma base de datos.
Es un reto mayor que una aplicación simple porque un fallo de aislamiento no es un error visual: es información de un negocio visible para otro. Por eso el aislamiento se diseña como parte de la arquitectura y se comprueba con pruebas, no se deja a la memoria de quien escribe cada consulta.
Arquitectura pensada para crecer por módulos
La plataforma se organiza en módulos con responsabilidades separadas, tanto en el backend como en el frontend. Cada módulo se puede activar por organización. Estado actual:
Administración
Organizaciones, usuarios, roles y configuración de cada negocio.
Desarrollado
Facturación
Facturas, series, impuestos, pagos, cierre de caja y una capa técnica orientada a requisitos fiscales.
Desarrollado
Salón y peluquería
Reservas, servicios, profesionales, calendarios y disponibilidad.
Desarrollado
Gimnasio
Salas, espacios, calendarios, profesionales, asistencia y cobros.
Desarrollado
Separar los módulos permite añadir nuevos tipos de negocio sin tocar el núcleo y mantener controlado el acoplamiento entre ellos.
Reservas y operaciones
Un sistema de reservas parece sencillo hasta que hay que garantizar que dos personas no ocupan el mismo hueco, que las reglas de duración se respetan y que todo es coherente entre varias organizaciones. Estos son los retos de ingeniería que aparecen:
- Cálculo de disponibilidad a partir de servicios, profesionales, calendarios y espacios.
- Servicios combinados con reglas de duración.
- Prevención de solapes cuando dos peticiones llegan a la vez, comprobada con pruebas concurrentes.
- Cancelaciones que conservan el histórico en lugar de borrar la reserva.
- Notificaciones en tiempo real a la aplicación cuando cambia una reserva.
No es una descripción funcional del producto, sino de los problemas técnicos que hay que resolver bien para que un sistema de reservas sea fiable.
Facturación y VERI*FACTU
Lavorial incorpora un módulo de facturación con facturas, facturas simplificadas, rectificativas, series, impuestos y retenciones, borradores con control de duplicados, generación de PDF y cierre de caja.
Sobre esa base se ha desarrollado una capa técnica orientada a los requisitos de VERI*FACTU, contrastada con la documentación oficial de la AEAT. Incluye registros de facturación encadenados por huella, código QR, construcción de los registros en XML y su validación contra los esquemas publicados, gestión de respuestas, reintentos y recuperación, subsanación e intervención manual cuando un registro lo requiere.
Importante: el envío real a la AEAT está desactivado por código mientras se completan las validaciones necesarias. Por eso no afirmamos que Lavorial cumpla completamente VERI*FACTU ni que esté certificado. Lo que mostramos es el trabajo de ingeniería realizado sobre un requisito normativo complejo.
APIs e integraciones
Una plataforma SaaS no es una aplicación aislada. En Lavorial, el frontend se comunica con el backend mediante una API, y el backend se integra con servicios externos, como la pasarela de pagos para la contratación y el servicio de la AEAT para la parte fiscal.
Las integraciones con servicios externos usan procesos en segundo plano con reintentos para que un fallo temporal no pierda información, y procesan los avisos de terceros de forma idempotente, de modo que recibir dos veces el mismo aviso no duplique efectos.
Es el mismo enfoque que aplicamos en nuestro servicio de integración de sistemas y APIs.
Inteligencia artificial
Junto a la plataforma se ha desarrollado un servicio de chatbot como microservicio separado, que puede conectarse con el backend de Lavorial. Para ello, el backend expone endpoints protegidos con una clave de servicio que permiten consultar los servicios, los profesionales y los huecos disponibles de una organización, y crear reservas.
El servicio puede trabajar con distintos proveedores de modelos, locales o externos, y se adapta a cada tipo de negocio mediante instrucciones y herramientas específicas por dominio.
Se plantea como una pieza separada del núcleo de Lavorial, para poder cambiar de modelo o proveedor sin tocar la plataforma. Describimos aquí la arquitectura desarrollada, no su uso en producción ni resultados.
Si quieres valorar un caso parecido en tu empresa, consulta nuestro servicio de inteligencia artificial para empresas.
Evolución tecnológica
A medida que aumentan los requisitos de un producto, la arquitectura también evoluciona. Lavorial empezó con un backend en Python y FastAPI, y se ha migrado a .NET con una solución dividida en capas (API, aplicación, dominio e infraestructura).
La base de datos de referencia es hoy MySQL 8.0, gestionada con Entity Framework Core y migraciones versionadas. Con la migración llegaron prácticas que antes no existían o estaban menos formalizadas: filtros globales por organización, procesos en segundo plano con patrón Outbox, límites de peticiones, trazabilidad con OpenTelemetry y comprobaciones de salud.
Cada decisión relevante queda registrada en documentos de decisiones de arquitectura (ADR) dentro del repositorio.
Calidad y pruebas
El backend contiene actualmente más de 1.700 declaraciones de pruebas automatizadas entre pruebas unitarias y de integración. La cifra corresponde al estado del repositorio en octubre de 2026 y no representa por sí sola la cobertura del código.
- Las pruebas de integración se ejecutan contra una base de datos MySQL real en contenedor.
- Hay pruebas de concurrencia para reservas, numeración de facturas y avisos de pagos.
- Hay pruebas de aislamiento entre organizaciones.
- El frontend tiene su propia suite de pruebas con Vitest.
Las pruebas no garantizan la ausencia de errores, pero dan una red de seguridad para evolucionar el producto sin romper lo que ya funciona.
Despliegue e infraestructura
La arquitectura de despliegue es la habitual en un producto SaaS moderno: frontend desacoplado, API, base de datos y contenedores.
- Frontend como aplicación web separada.
- Backend como API en contenedor Docker, con un usuario sin privilegios de administrador.
- Base de datos MySQL separada de la aplicación.
- Configuración preparada para distintos entornos de desarrollo, pruebas y producción.
- Comprobaciones de salud del servicio y verificación automatizada de la imagen del contenedor.
No detallamos aquí proveedores, direcciones ni configuración interna.
Decisiones técnicas importantes
Estas cuatro decisiones resumen el criterio con el que se ha construido el producto:
Aislamiento entre organizaciones
- Problema
- Los datos de un negocio no pueden ser visibles para otro, y depender de que cada consulta recuerde filtrar por organización es frágil.
- Decisión
- Filtros globales de Entity Framework Core vinculados a la organización actual, filtros explícitos donde el acceso no viene de un usuario autenticado y pruebas entre organizaciones.
- Motivo
- Una red de seguridad estructural que no depende de la disciplina de cada consulta.
Procesos en segundo plano con Outbox
- Problema
- Acciones como el envío fiscal o las notificaciones no deben perderse ni bloquear la operación que las origina.
- Decisión
- Patrón Outbox y trabajos en segundo plano con reintentos.
- Motivo
- La operación principal termina rápido y las acciones secundarias se completan de forma fiable.
Módulos activables por organización
- Problema
- Cada tipo de negocio necesita funciones distintas y el núcleo no debe crecer sin control.
- Decisión
- Módulos separados (salón, gimnasio, facturación) con acceso controlado por organización.
- Motivo
- Permite añadir verticales sin rehacer lo existente.
Envío fiscal real cerrado por código
- Problema
- Un cambio de configuración no debería poder activar por error el envío real de registros a la administración.
- Decisión
- El envío real permanece bloqueado en el código hasta completar las validaciones, y la capa fiscal se desarrolla y prueba sin él.
- Motivo
- Reduce el riesgo en un ámbito donde un error tiene consecuencias legales.
Tecnologías
Estas son las tecnologías que forman parte significativa del desarrollo:
Backend
- C# y .NET 10 (ASP.NET Core)
- Entity Framework Core
- Hangfire, SignalR y patrón Outbox
Frontend
- React y TypeScript
- Vite
- Vitest
Datos
- MySQL 8.0
- Migraciones con Entity Framework Core
Infraestructura
- Docker
- OpenTelemetry y comprobaciones de salud
IA
- Microservicio de chatbot en Python
- Compatible con varios proveedores de modelos
Qué demuestra este proyecto
Lavorial muestra, con hechos, el tipo de trabajo que Julmen puede hacer para otras empresas:
- Diseñar la arquitectura de un producto de software completo.
- Desarrollar backend, frontend y base de datos.
- Construir y consumir APIs.
- Resolver sistemas multiempresa con aislamiento de datos.
- Integrar servicios externos de forma fiable.
- Aplicar automatización y trabajo en segundo plano.
- Diseñar la integración de inteligencia artificial como una pieza desacoplada.
- Desplegar con contenedores y comprobaciones de salud.
- Probar el software de forma sistemática.
- Evolucionar un producto real a medida que cambian los requisitos.
Es la experiencia que aplicamos en nuestros proyectos de software a medida.
¿Tienes un problema que necesita una solución a medida?
Lavorial demuestra capacidad técnica para un sistema complejo, pero el alcance depende del problema: no hace falta que necesites un SaaS de reservas. Puede ser software interno, una aplicación, una integración o una automatización, grande o muy acotada. Cuéntanos qué necesitas y evaluamos cómo abordarlo.