Series: PENB Energy Label Approximation – Lessons from Building a Public Application

Series goal:
Describe the project from problem definition through data and modeling to public deployment, highlighting where data science, product thinking, and quality implementation meet.

Related Parts

1. Why waiting for a formal audit isn’t enough – when an indicative calculation is more useful than waiting.
2. How to turn regular consumption into valid input – what needs to be prepared before the model can start.
3. Weather, heating season, and an RC model without magic – where domain logic meets data.
4. How to turn a calculation into an app for everyday users – why UX is more than just cosmetics.
5. Deployment, limitations, and what’s next – what works today and what should come in the next iteration.

Part 1: Why waiting for a formal audit isn’t enough

Where the real problem started

A formal PENB makes sense when you need to meet a legal requirement or need a final document for sale or rental. But most decisions happen earlier.

People want to know:

• if their consumption is normal,
• whether it’s worth investing in apartment improvements,
• if a specific apartment is suspiciously energy-intensive,
• whether it makes sense to proceed with deeper analysis.

At this stage, a formal audit is usually too slow. You need a quick but still defensible signal.

The hardest part isn’t the calculation, but defining the problem correctly

Projects like this clearly show the difference between a technically interesting model and a practically useful product.

The technical question is:

Can you estimate an apartment’s energy consumption from operational data?

The product question is different:

Can you quickly and clearly help someone decide whether it’s worth analyzing their apartment in detail?

The second question is more important. That’s why this app wasn’t created as a replacement for a certified PENB, but as a tool for initial orientation.

Why operational data makes sense

People often don’t have the building’s technical documentation at hand, but they do have:

• bills and consumption data,
• basic apartment parameters,
• information about the heating source,
• a rough idea of how they use the apartment.

It’s not a perfect dataset. But it’s a dataset that actually exists. And a good product often starts where data is truly available, not where it would be ideal.

What such a tool must deliver

For the app to be useful, it must meet four criteria:

• be fast, so it helps even before a formal audit,
• be clear, so the result isn’t just another technical barrier,
• openly acknowledge limitations, because uncertainty can’t be hidden,
• be publicly accessible, so the principle can be demonstrated immediately in practice.

That’s also why the project didn’t end up as just a notebook script. From the start, it was headed toward becoming an application.

The value for users is in decisions, not just numbers

The energy class itself is only part of the result.

The greater value is that the application helps answer practical questions:

• is it worth continuing with due diligence,
• is the consumption consistent with the apartment’s parameters,
• is it appropriate to plan a renovation,
• is it worth ordering a detailed audit.

In other words: the project stands out because it turns unclear operational data into an actionable framework for the next step.

What’s next

In the next part, I’ll look at why it’s critical for this kind of application to properly prepare input data, how to separate heating from regular usage, and why input validation often matters more than model optimization itself.