I joined Klar as a junior developer when it was two people: me and a founder. Four years later I’m the frontend lead, and the platform serves over 2,000 DTC brands across Europe.

What Klar does

Klar gives eCommerce brands a single place to understand their business — marketing attribution, profitability, retention, creative performance. The kind of data that used to live in five different spreadsheets, each one slightly wrong.

The frontend is where all of that becomes usable. Charts, dashboards, filters, cohort tables, attribution flows. Complex data that has to feel simple. That’s what I build.

What I walked into

The codebase worked. It shipped features. But the logic was tangled through the views, tests didn’t exist, and releasing anything required confidence in a process that didn’t deserve it. Long-lived feature branches, manual merges, the kind of release dread that slows teams down even when nobody says it out loud.

It wasn’t broken. It was fragile.

What I changed

I started with the foundation that makes change safe: tests and feature flags. We went from 0% test coverage to 78% in nine months — not by writing tests for their own sake, but by testing the logic that actually mattered. Feature flags came alongside: no more long-lived branches, no more merge anxiety. We ship to production continuously, and flags let us do it safely — features can be in production before they’re visible to users.

That confidence is what made the bigger change possible. With a safety net in place, I introduced a strict layer model across the frontend:

Views handle only the UI — no logic allowed
Use cases orchestrate user journeys
Services hold domain logic
Repositories manage state access
Adapters handle everything external

Each layer has one job. That clarity made the codebase navigable and safe to change — and because the tests were already there, we could refactor without fear of breaking things quietly.

The result wasn’t raw speed. It was confidence. The team ships without fear, and that changes what you’re willing to attempt.

What I’ve built

Over four years I’ve touched every part of the product. Some of the harder problems worth calling out:

Flexible data source configuration — Users can build their own data source customizations through a dynamic form that supports arbitrary nesting. The underlying data transformations and validations have to work regardless of how deep or unusual the structure gets. Getting that right was hard.

Persistent dashboard state — Every user’s dashboard view is stored and restored between sessions. That sounds straightforward until the product evolves: features change, configuration shapes shift, new properties appear. Keeping stored state valid across product changes — without breaking sessions or losing data — is an ongoing engineering challenge.

Dashboard render engine — Currently in progress. Moving away from dashboards defined in code toward a configuration-driven render engine: one engine that reads any dashboard configuration and produces the right visualisations. This will make the product dramatically more flexible and the codebase significantly leaner.

The team

When I was promoted to lead, there was one other frontend developer. There are now five. I hired and continue to mentor the team. The architecture standards, the testing culture, the trunk-based workflow — those are the foundation the team builds on.

Getting promoted wasn’t something I waited for. I treated the product like it was mine — cared about the users, took ownership of problems, asked the questions that others didn’t. The promotion followed the behaviour, not the other way around.

Stack

React 19 with React Compiler, TypeScript, Redux Toolkit, RTK Query, Vite, Vitest, React Testing Library, Playwright, Cloudflare Pages.