.png)
Complex valuations. Smoother workflows.
Leonh
Making the existing features easier to work with
A strong core, growing complexity
I joined Leonh while their product, Infinity, was already functional and built on deep domain expertise. The core logic was solid, but the interface and workflows hadn’t yet caught up with the complexity the product needed to support. The work wasn’t about adding features, it was about making what already existed easier to work with as the product continued to grow.
.png)
%202.png)
Capable software, evolving structure
From a development perspective, Infinity could already do a lot. From a product and design perspective, some structural aspects needed to evolve. The dashboard was organised in parts, workflows varied between sections, and UI decisions were often made locally, screen by screen. This made it harder to reason about the product as a whole, and harder for engineering to build with long-term confidence. Nothing was fundamentally broken, but there was an opportunity to anchor things more clearly.
Speed and clarity at the same time
The main tension wasn’t visual or feature-driven. It was about pace. As a startup, Leonh needed to move quickly and stay lean. At the same time, continuing without shared structure risked creating patterns that wouldn’t scale, or that would need to be revisited later. The questions shaping the work became:


Structure before polish
My focus was on helping define a foundation the team could realistically build on. This meant establishing a clearer dashboard structure, aligning key workflows across the product, and defining component rules and interaction logic in close collaboration with engineering. I deliberately deprioritised visual refinement. At this stage, clarity mattered more than polish. I also chose not to redesign everything, keeping parts of the existing interface intact helped preserve logic that was already working and allowed the team to maintain momentum.

From local decisions to shared reference
Once structure and rules were in place, the nature of the work changed. Design conversations gradually moved from “How should this work?” to “What should we build next?” The team gained a shared frame of reference for layouts, components, and workflows, reducing the need to revisit foundational decisions.

Working closely with engineering
A large part of the work happened in close dialogue with engineering. Component logic and layout decisions were shaped around what could realistically be built, what needed to stay flexible over time, and where consistency mattered more than configuration. The goal wasn’t to define a perfect system, but a usable one the team could extend without rethinking the basics each time.


Clearer, not finished
By the end of my involvement, Infinity had a clearer foundation: defined core workflows, a more coherent dashboard structure, and component logic that supported continued development. The product wasn’t, and didn’t look, finished. But it was no longer ambiguous at a structural level, making future work easier to reason about and build on.

