Greenbyte SaaS + Mobile

Greenbyte (now part of Power Factors) ships an energy SaaS suite for the renewables sector, Kalenda, Millwatcher, EnergyMaster, Roberta and Vindmøllenet, used by operators across wind, solar and storage. The flagship line is the energy platform itself; Kalenda is the product within the suite that handles calendar, maintenance scheduling and field-work planning, with a web application and a mobile companion. It is the kind of domain where a missed service window or a misread schedule has a real-world cost, and where the people on the other end of the product live in the data day-in, day-out.

I joined in November 2021, initially as a student software engineer alongside my MSc, and continued full-time after graduation until September 2024. Just shy of three years. The bulk of my work sat on Kalenda, with the rest spread across other parts of the suite as the team needed it. The stack split into two halves:

• .NET Core with Entity Framework Core on the back end and React on the front end, sitting on top of MS SQL Server, for a meaningful slice of the web platform. The usual full-stack mix: domain modelling, API design, query and performance work, the bits that come from caring about correctness as much as features.
• Java with Spring, Hibernate, JSP and Tomcat for backend functionality elsewhere in the codebase. Older surface, plenty of personality, and the kind of work that teaches you to add new behaviour without making the existing behaviour worse.

The piece I am proudest of is the mobile companion app. I was the architect and lead developer of a Flutter / Dart mobile client that brought a focused subset of Kalenda to phones and tablets, both for engineers in the field and for managers who needed the headline numbers without sitting at a desk. Owning a product end-to-end at that scope was formative:

• Architecture from a clean sheet. Picking the right state-management and navigation patterns for a multi-screen Flutter app, defining the layering between platform API, domain, and presentation, and making sure the choices held up as the surface area grew.
• API design across the boundary. Designing the back-end-for-frontend contracts the mobile app would consume: small, predictable, mobile-aware endpoints rather than re-using the web's shape, and shipping the back-end side of those alongside the Flutter side.
• Domain modelling. Mapping a data model that originated in the web product into something a mobile UI could navigate without paging the user to death, and pushing back on design proposals that would not survive a flaky cellular link out in the field.
• Performance. List-rendering, image handling, network retries, perceived responsiveness: the unglamorous mechanics that decide whether a mobile product feels good or feels cheap.
• Lead-developer responsibilities. Code review, onboarding new contributors to the codebase, owning the release pipeline for both stores, and being the person the rest of the team looked to when a Flutter or Dart question went deeper than the usual stack-overflow answer.

Around the feature work I held internal seminars on ReactJS, Flutter and quality guidelines for the rest of the engineering team, a small mentoring track that paired naturally with the lead-developer responsibilities on mobile. The DevOps research I did with Greenbyte for my master's thesis at Aarhus University grew directly out of working in that environment: an honest study of what made adoption stick, and what stalled it, in a small-to-mid-sized engineering organisation.

Three years was long enough to see features move from sketch to production to retirement, long enough to feel ownership for the parts I built, and long enough to leave with a clear sense of the trade-offs that small product teams quietly make every week.