May 2026 at Monolith - Faster Workflows, Better Control, Less Friction

May was about improving the entire user experience

In May 2026, we did not focus on a single "big launch." Instead, we improved many parts of the product that together create a much better experience of working in Monolith. From a product team perspective, many of these changes are infrastructural. From a customer perspective, they mean something very concrete: less friction, faster decisions, and better control over the project.

We invested most heavily in three areas:

• simpler access to the product and pricing plans,
• faster work on materials and design variants in Terra,
• more mature data and workflows that users can genuinely rely on.

1. Access to the product became clearer

One of the most important moments in any SaaS product does not happen inside the calculator or the dashboard. It happens when a user is trying to understand what they are buying, how access works, and whether they can adopt the product in their day-to-day workflow without adding unnecessary complexity.

In May, we made this part of the experience much more structured:

• we added a more visible path to pricing and plan information,
• we expanded the subscriptions experience,
• we introduced plan- and product-based access restrictions,
• we built the technical foundation for smoother access activation.

For the end user, this creates clearer answers to three basic questions:

• what can I use,
• which plan is right for me,
• what happens after access is activated.

This matters especially for smaller design offices and specialists who do not want to go through a complicated onboarding process. Monolith should be a tool that is easy to start using quickly and easy to understand without having to decode the entire product architecture first.

2. Terra made day-to-day work on materials faster

The biggest share of May's work went into Terra, the part of Monolith where project teams work with materials, assignments, and LCA results. This is where users feel very quickly whether the product is helping them move forward or simply adding another layer of operational overhead.

In May, we added and refined features including:

• a material alternatives tab,
• the ability to remove material assignments,
• better handling of empty project states,
• clearer units and simpler edit forms,
• layout and view stability improvements.

From a business perspective, this is a very meaningful shift. Users do not come to Monolith simply to "view data." They come to compare options faster and make better project decisions. Every extra click, unclear field, or need to manually move back and forth between views slows that process down.

After the May updates, Terra supports this real working mode much better:

• it is easier to evaluate an alternative,
• it is easier to correct a poor choice,
• it is easier to keep the project organized,
• it is easier to move from material data to a decision.

These are the kinds of improvements that may not always look dramatic in a demo, but they strongly influence whether a user wants to come back to the product the next day.

3. Transport and LCA analysis became more realistic

In material-related projects, details matter. That is why in May we expanded transport handling and improved several important parts of the analysis itself.

The most important changes in this area included:

• support for multiple transport methods,
• better UI presentation for multiple transport entries,
• fixes to CO2 calculations for materials,
• cleaner charts and results views,
• CSV export,
• A4 export.

For customers, this translates into two meaningful outcomes.

First, results are closer to real project conditions. Second, they are easier to share with a client, partner, investor, or internal project stakeholders. A professional tool cannot stop at the screen. It also has to support users when results need to be defended, compared, or passed along.

4. We laid the groundwork for smarter recommendations

Some of May's work is not yet visible on the first screen, but it matters greatly for the direction of the product. We continued developing the backend for suggestions, benchmarks, and better organization of project data.

This area included work such as:

• endpoints for suggestions,
• benchmark reindexing in the gateway layer,
• embedding material data directly into the project,
• continued cleanup of project logic and permissions.

Why does this matter to the end user if not all of it is visible yet? Because a good product is not built only from new screens. It is also built on an architecture that allows features to evolve without losing consistency, performance, or trust in the data.

This is an investment in a future version of Monolith where project decisions are supported not only by a static data source, but also by increasingly capable comparison and recommendation mechanisms.

5. Spark gained a more structured workflow foundation

May was also important for Spark, our product line for building energy performance workflows. The most visible progress here was the expansion of the data model and the forms required to run an energy project with greater structure.

We expanded areas including:

• core project data,
• building characteristics,
• energy models,
• the main heating system,
• domestic hot water,
• selected technical parameters and validation.

This is not the end of the journey for Spark, but it is an important milestone. For users, it means a more structured way to enter data, less ambiguity in the forms, and a stronger foundation for the next stage of the calculation layer.

In practice, we are building a product that should guide specialists through a complex process in a way that feels more modern than traditional desktop tools. The May updates moved us closer to that goal.

What this means for customers today

If we look at May not as a list of commits but as market-facing value, four concrete outcomes stand out:

• easier entry into the product and better understanding of plans,
• faster work on materials and variants in Terra,
• more reliable results that are easier to share,
• a stronger foundation for scaling the capabilities users will benefit from in the coming months.

This matters to us because Monolith is not meant to be only a technically correct system. It is meant to be a tool that genuinely shortens the distance from data to decision. In May, that is exactly the distance we kept reducing.

What comes next

In the next phases, we want to keep strengthening two core pillars of the product:

• day-to-day usability in Terra,
• the computational and workflow maturity of Spark.

At the same time, we are continuing to improve access, subscriptions, and product logic, because we know that for the end user it is not only the feature itself that matters, but the entire experience of using the system from first access to final output.

May 2026 was a month of practical progress for Monolith. We did not just add new elements. We continued building a product that is easier to buy, easier to adopt, and easier to value for the teams who will rely on it every day.