michaelprinc.com

Tag: streamlit

  • PENB Label Approximation – Part 4: Turning the Calculation into an App for Everyday Users

    Part 4: Turning a Calculation into an App for Everyday Users

    Why the Right Model Isn’t Enough

    Many technical projects fail not because the model is wrong, but because real users can’t interact with it. For a PENB approximation app, this is especially important since the target audience isn’t just analysts.

    A usable public app must meet three requirements at once:

    • the user must understand what to enter,
    • the system must receive consistent input,
    • the output must be readable even without deep technical knowledge.

    Five Steps Instead of One Overwhelming Screen

    The current interface uses a logical breakdown into several steps: location, apartment, data, calculation, and result. This is important for practical reasons.

    When people see everything at once, it’s easy to lose context. Guiding them step by step increases the chance of correct input.

    This isn’t just a UX rule. It’s also a way to improve the quality of data that ultimately reaches the model.

    The Form as Part of Domain Logic

    A public app shouldn’t just be a thin layer over the backend. In this project, the form actively helps structure the input:

    • guides users to the truly essential information,
    • distinguishes between quick and detailed calculation modes,
    • handles months without heating and hot water right at input,
    • sets the stage for interpreting the result.

    From this perspective, UX is not separate from data science. It’s one of the layers that determines whether the model receives meaningful input.

    The result must be understandable, not just accurate

    The user usually doesn’t need to know all the internal calibration parameters. They need to understand:

    • what energy class the calculation yields,
    • how reliable the estimate is,
    • what the interpretation limits are,
    • what the next logical step is.

    That’s why the output combines the energy class, key metrics, a written comment, and an exportable report. The result serves as a communication artifact, not just a technical intermediate output.

    Bilingualism as a product feature

    An interesting part of the project is that the application isn’t just prepared for local testing. It has both Czech and English language versions. This increases usability for project presentations, sharing with clients, and further development.

    Technically, this means more work. But from a product perspective, it significantly boosts the application’s overall value.

    What’s next

    In the final part, I’ll cover deployment, report export, current project limitations, and what I would expand or refine in the next iteration.

    Previous part
    Next part
    Project case study

  • PENB Label Approximation – Part 5: Deployment, Limitations, and What’s Next

    Part 5: Deployment, limitations, and what’s next

    When does a project become a real project

    As long as the calculation only runs locally, it’s just an experiment. The moment you can open it at a public URL, switch languages, go through the workflow, and download a report, it starts to become a real product.

    That’s the case with this app. The computational logic matters, but it’s just as important that it’s deployed as a publicly accessible service.

    What brings operational value

    Today, the project stands on several practical building blocks:

    • containerized deployment in Docker,
    • separate Czech and English versions,
    • persistent storage for local state and reports,
    • HTML export of results,
    • clear separation of UI, model, and reporting layer.

    These are exactly the elements that determine whether the app can be further developed without rewriting it from scratch.

    Transparency about limitations is part of quality

    For a tool like this, it’s important not only what it can do, but also what it can’t do yet or only handles approximately.

    With the current implementation, it’s good to be open about, for example:

    • the output is indicative, not a certified PENB,
    • the reference year in the MVP is an approximated typical year, not a full TMY dataset,
    • result quality depends on the scope and consistency of input data,
    • some parts of the result presentation still have room for further development.

    This is not a weakness in communication. It’s its professionalization.

    What I would develop in the next iteration

    If the project were to continue to the next version, I believe these directions would make the most sense:

    • more precise handling of the reference year and climate scenarios,
    • expanding the interpretation of results with further recommendations,
    • deeper work with visualizations and calibration explanations,
    • more robust handling of a wider range of input situations.

    These steps would not only advance the technical side of the model. They would also increase user trust in the output and the ability to use the tool in real decision-making.

    Key takeaways from the whole series

    The PENB approximation project clearly shows that a quality data application doesn’t arise from a single clever idea. It emerges from the interplay of several disciplines:

    • choosing the right problem,
    • a reasonable model,
    • a quality data workflow,
    • a usable interface,
    • and deployment that allows the result to be truly used.

    This combination, in my view, is more interesting than the mere fact that the application returns an energy class.

    Previous part
    Project case study
    Open the application

michaelprinc.com

Data Scientist & ML Engineer from Prague

© 2026 Michael Princ. All rights reserved.

Built with WordPress