Monolith - a platform for the new standard of sustainable construction

Monolith was born from a very specific problem

The construction industry is entering a phase where regulatory requirements, investor expectations, and cost pressure are all increasing at the same time. On one hand, teams have to prepare increasingly complex energy analyses. On the other, environmental data, the carbon footprint of materials, and a broader life-cycle view of the building are becoming more important.

For many teams, that means working across several tools at once, manually transferring data, facing a high risk of errors, and dealing with a steep barrier to more advanced analysis. Monolith was born directly from that observation.

We are building Monolith as a SaaS platform for sustainable construction that brings together two areas that have traditionally been handled separately:

• building energy performance,
• life-cycle carbon footprint analysis, or LCA.

From the start, our goal was not to create yet another closed calculator. We want to build a modern, browser-based workspace where a specialist can move from project data to energy and material decisions without constantly jumping between systems.

The problem we are solving

Today’s market has three clear weaknesses.

First, regulatory changes, including new requirements emerging from the EPBD 2024 direction, are increasing the complexity of calculations and documentation. Second, many LCA tools remain too expensive for small and medium-sized firms. Third, existing solutions are siloed: one program for energy, another for materials, and another for reporting.

In practice, this hurts people who are already working under time pressure. An auditor does not want to manually rewrite data between systems. An architect does not want to buy expensive enterprise software just to compare material variants faster. A developer or project team does not want to wait weeks for an answer to a basic question: what effect will these decisions have on the project’s energy and environmental outcome?

Monolith is meant to lower those barriers. We focus on browser-based access, centrally updated methodologies, and a lower cost of entry than many specialized tools available on the market today.

Who we are building Monolith for

Very quickly, our product materials showed that our customer is not simply "everyone in the industry." We are designing Monolith for specific people and their real responsibilities.

The first is Spark - an energy auditor or certifier who needs to work quickly, accurately, and confidently through growing formal requirements. This person values regulatory compliance, a predictable workflow, and a tool that does not force them to wrestle with outdated UX.

The second is Terra - an architect or designer who wants to make better material and environmental decisions without adopting an expensive, heavy enterprise system. What matters to them is the ability to compare variants quickly, get a clear result, and enter LCA with a low barrier to entry.

These two profiles are exactly what we used to shape the core logic of the product.

Two products, one direction

We are developing Monolith across two main product lines.

Spark

Spark is the building energy performance module. Its role is to organize the complex energy analysis process and guide the user through input data in a way that is more modern and clearer than traditional desktop tools.

It is a product for specialists who:

• prepare energy analyses and certificates,
• work under deadline pressure,
• do not want to rewrite data or manually work around the limitations of old software,
• need a solution ready for further market and regulatory changes.

Terra

Terra is the LCA module focused on the carbon footprint of materials and the project as a whole. It makes it possible to search for materials, assign them to a project, analyze variants, and make more informed design decisions.

It is a product for teams that:

• want to compare materials faster,
• need a more practical entry point into LCA,
• are looking for a tool that supports design decisions rather than slowing them down with additional procedures,
• want environmental data to sit closer to the project work they do every day.

The most important idea behind Monolith is broader than a split into two modules. Our target advantage is that results from the energy side should feed into the LCA side, especially where the building’s use phase matters. That means less manual work, fewer errors, and one view of the building instead of several disconnected spreadsheets and programs.

Why web, not another desktop application

In many construction niches, tools still dominate because they built market position over the years, even though technologically and from a UX perspective they no longer keep up with user expectations. From our point of view, this is not just an aesthetics problem. It is a real productivity problem.

Monolith’s web architecture brings several advantages:

• access to the system without installation,
• centralized updates to methodologies and databases,
• easier rollout in small teams,
• the ability to build a single environment for energy and LCA,
• a stronger foundation for developing a SaaS subscription model.

This matters especially for SMEs, which do not have the time or resources for heavy implementations, while at the same time feeling growing pressure around compliance, documentation, and responsible design.

Where we are today

Monolith sits somewhere between a PoC and an MVP, but it is no longer just a concept. The repository already shows a real multi-module product with frontend, backend, authentication, access plans, and separate paths for Spark and Terra.

Terra is currently the more mature part. Today, the product already has the foundations needed for practical work:

• a project list and project creation flow,
• a project screen with tabs,
• material database search and browsing,
• assigning materials to a project,
• editing assignment parameters,
• LCA results visualizations,
• CSV export.

On the backend side, support already exists for projects, material assignments, pagination, filtering, transport profiles, and LCA result aggregation. That matters because it shows that Monolith is not stopping at the marketing layer, but is building a real data and workflow engine.

Spark is already very strong from a product and UX perspective. It has its own identity, landing page, project list, forms, validations, and a data structure covering many sections needed for a building energy analysis. At the same time, we want to be honest that the calculation layer is still in a transitional phase. In other words: the direction is clear, the interface and workflow model are in place, but fully completing the calculation engine remains one of the key next development steps.

What the technical foundation looks like

From an implementation perspective, Monolith is being developed as a cohesive web product.

The frontend is built on React, TypeScript, Vite, React Router, Material UI, and a modern forms and validation stack. The backend api-gateway-service runs in Go and is responsible for the HTTP layer, authorization, data access, project handling, and the logic needed for the platform’s continued growth.

What matters to us is not only what we calculate, but how we structure it architecturally. Responsibilities are split into layers, routing depends on access to products, and the subscription model is already reflected in the system. That is a strong foundation for scaling further and introducing new features without rebuilding everything from scratch.

What we see as our advantage

We do not believe Monolith’s advantage will come from a single screen or a single table. Our advantage needs to be systemic.

First, we combine domain expertise and technology. This is a project built not just as software, but as a tool grounded in the industry’s real analytical workflow.

Second, we are targeting an area where the market is both imperfect and increasingly urgent. Energy tools are often historically strong but technologically weak. LCA tools can be functionally powerful, but financially inaccessible to a large part of the market.

Third, we want to deliver one working environment where others still force the user to separate energy, materials, and reporting into distinct systems.

What comes next

The next stage for Monolith is to keep closing out Spark, strengthen the advantages of Terra, and connect both areas more tightly into a single workflow. In parallel, business validation is also important to us: customer willingness to buy, the go-to-market strategy, and refining the growth model.

We know that correct software alone is not enough. The product must be methodologically sound, comfortable in everyday work, and economically accessible to the teams that will actually use it.

Monolith is moving in exactly that direction: it is meant to become a practical tool for a new standard of work in sustainable construction.