Saltar al contenido

Barcelona, España · 2025

Monolith nació para que una obra no tuviera que explicarse dos veces.

Un sistema operativo para conectar lo que se decide en oficina, lo que ocurre en campo y lo que necesita ver dirección.

Conocer el origen

01 · El origen

Una idea nacida cerca de la obra, no de una lista de funciones.

En 2025, Eugenio Rubido fundó Monolith en Barcelona a partir de una observación sencilla: los equipos de construcción trabajaban sobre la misma realidad, pero cada área veía una versión distinta.

El presupuesto cambiaba sin llegar a campo. Una incidencia de obra tardaba en aparecer en el coste. Una decisión importante perdía su origen al saltar de una llamada a una hoja de cálculo.

Monolith nació para cerrar esas distancias. No para sustituir el criterio del equipo, sino para darle una base compartida desde la que trabajar, revisar y decidir.

  1. 01

    La fricción

    La información de una misma obra vivía repartida entre hojas de cálculo, mensajes, llamadas y herramientas que no compartían contexto.

  2. 02

    La decisión

    En lugar de sumar otro módulo aislado, Monolith empezó a diseñarse como una base común para presupuesto, producción y dirección.

  3. 03

    El sistema

    Cada dato debía conservar su origen y acompañar a la decisión que afecta al coste, al plazo o a la ejecución de la obra.

02 · Lo que resuelve

El problema no era la falta de software. Era la pérdida de contexto.

Monolith conecta el recorrido completo de una decisión para que el dato no cambie de significado cuando cruza la empresa.

A

Oficina

Presupuesta, compra, revisa costes y prepara certificaciones.

B

Obra

Ejecuta, mide, registra incidencias y explica lo que ocurrió.

C

Dirección

Decide con una lectura común del avance, el riesgo y el margen.

Una única trazabilidadPresupuesto → ejecución → coste → certificación
Dos profesionales revisando una obra en construcción
Una conversación cerca de la obra

03 · El fundador

“Si una decisión cambia el coste, el plazo o la ejecución, ese cambio debe viajar con su origen.”
Eugenio RubidoFundador de Monolith

04 · Cómo construimos

Tres principios para un producto que vive a la velocidad de la obra.

  1. 01

    Contexto antes que funciones

    Una herramienta aporta valor cuando explica de dónde viene un dato, qué decisión lo cambió y a qué parte de la obra afecta.

  2. 02

    Trazabilidad sin burocracia

    Registrar bien no debería significar repetir el trabajo. Monolith busca que la información viaje mientras el equipo avanza.

  3. 03

    Tecnología que se retira

    La interfaz debe reducir ruido y dejar delante la obra, sus decisiones y las personas responsables de ejecutarlas.

05 · Lo que sigue

La obra cambia cada día. El sistema también debe avanzar.

Monolith sigue creciendo con una dirección clara: menos información repetida, más decisiones conectadas y una lectura común de cada obra.