MR/01

Selected work for PostHog
UX × Product × Engineering

PORTFOLIO / 2026 / PRAGUE

Products I've
helped build.

Four projects where I worked across product thinking, interface design, and engineering. I've tried to explain what I did, why I made those choices, and what changed as a result.

UX thinkingProduct ownershipProduction engineering

SELECTED CASE STUDIES

01CoralMaking a CLI product easier to understand↓02Metaphysic / BrahmaReusable components for ML workflows↓03KartaAn iOS golf app built from scratch↓04PipedriveFrom user interviews to production↓
01

CORAL / AI DATA RETRIEVAL / CLI + DESKTOP LAYER

Making a CLI product
easier to start with.

The CLI was powerful once you understood it. The product problem was everything before that moment: helping an interested visitor download Coral, connect their world, and experience why it mattered without having to learn the system first.

THE OPPORTUNITY

The CLI worked. Getting started was the hard part.

Coral was a CLI that ran entirely in the terminal. I explored how a small desktop layer could make onboarding clearer without trying to move the whole product into a UI. I proposed packaging the CLI as an app, adding a simple onboarding flow, and using UI only for the parts that benefited most from it: connecting sources and agents, seeing system state, and tracing what an agent did.

THE PRODUCT DECISIONS

  1. 01Package the CLI.

    Run it as an Electron sidecar so installation did not require users to assemble the tooling themselves.

  2. 02Explain the setup.

    Make sources, permissions, agent connections, and system state visible and sequential.

  3. 03Start with a useful prompt.

    Open the connected agent with a prompt already attached, so users could see a meaningful result without having to invent a test.

  4. 04Show what happened.

    Add tracing and query inspection for the moments when the CLI could not explain what an agent did or why.

CORAL DESKTOP / 01 OF 03
Editorial illustration of Coral's CLI surrounded by focused desktop interfaces for sources, traces, and agents
01 / CLI with a focused desktop layer

WHY ADD A UI?

Every interface surface answered one question in the adoption journey: What do I do next? Is it working? What value did it just create?

MY ROLE

Identified the activation problem, defined the desktop UX, prototyped it, presented the direction to the team, and implemented the shippable Electron app.

BUSINESS IMPACT

Turned a developer-oriented install into a guided product journey, shortened the path to a credible first result, and made agent behaviour inspectable enough to build trust.

WHAT THIS SHOWS

Product discovery inside an engineering problem; selective use of UI; end-to-end ownership from idea to packaged software.

02

METAPHYSIC / BRAHMA / ML WORKFLOWS

A workflow builder
the team could extend.

Brahma turned complex video and machine-learning operations into node-based workflows. As the frontend-focused engineer, my leverage came from enabling the rest of the engineering team to add capabilities without waiting for me.

BRAHMA / 01 OF 05
SYSTEM MODEL / REUSABLE NODE PRIMITIVES
INPUT / VIDEOExtract framesSource file
DATASET / FACEPrepare training set248 frames
MODEL / TRAINTrain identityGPU process
OUTPUT / COMPOSITEApply modelFinal render
01 / Workflow component model

THE SYSTEM

Reusable pieces instead of one-off screens.

I created reusable node primitives, controls, validation states, connection patterns, and GraphQL contracts. New ML operations became combinations of known parts rather than bespoke frontend projects.

The architecture matched the team: backend and ML engineers could expose new capabilities through a predictable schema and assemble a coherent UI with minimal specialist frontend work.

MY ROLE

Owned frontend architecture and interaction patterns for the workflow builder; translated ML concepts into stable, reusable product primitives.

BUSINESS IMPACT

Removed a frontend bottleneck, reduced the cost of adding workflow capabilities, and let a backend-heavy team ship new node types faster without fragmenting the experience.

WHAT THIS SHOWS

Systems thinking at the intersection of UX, API design, team structure, and long-term engineering velocity.

03

KARTA / SIDE PROJECT / IOS

Designing and building
a golf app from scratch.

Karta is a fun side project and creative outlet: a chance to define the product promise, visual identity, core flows, and native implementation from scratch. The constraint I set for the design was simple: scoring should be fast enough to disappear while a round is happening.

PRODUCT PRINCIPLES

A scorecard should
stay out of the way.

  • 01Start a round through a facility-first course finder.
  • 02Keep scoring local, private, offline, and crash-safe.
  • 03Make the common action possible with one thumb.
  • 04Turn the finished round into an elegant share card.
Product screens / 01—08Swipe to explore →
Karta home screen with recent rounds and a shortcut to the last played course
01 / Home and recent rounds
Karta course search showing recent and nearby golf courses
02 / Course discovery
Karta round setup for choosing starting hole and round length
03 / Round setup
Karta active round screen with score progress and controls
04 / Round in play
Karta scorecard with eighteen holes and missing-score guidance
05 / Full scorecard
Karta finish-round screen explaining a missing score and the available choices
06 / Useful edge cases
Karta round history showing completed and incomplete rounds
07 / The golf book
Shareable Karta round card showing a score of 42 over nine holes
08 / Finished round share card

MY ROLE

Product definition, naming and identity, interaction design, self-testing, course-data decisions, SwiftUI architecture, and implementation.

BUSINESS IMPACT

Took an ambiguous idea to a coherent, shippable iOS product and focused scope around a differentiated promise: a dependable private golf book, not another social feed.

WHAT THIS SHOWS

Zero-to-one product judgment, visual design, ruthless workflow prioritisation, and the ability to personally ship the result.

04

PIPEDRIVE / CROSS-PRODUCT CONVERSION

From interviews
to a shipped flow.

One project asked users to move data between two products that had previously been separate. I took on both product design and frontend implementation, keeping research, prototyping, and production in one feedback loop.

IMAGE SLOT / PIPEDRIVE FIGMA + FLOW
01 / LISTENUser interviews

External stakeholders
Needs and failure modes

→
02 / MAKEFigma prototypes

Conversion model
Key edge cases

→
03 / SHIPProduction UI

Frontend implementation
Instrumentation

→
04 / LEARNA/B testing

Observed behaviour
Iterated flow

ONE CONTINUOUS LOOP

Because I interviewed users, built the prototype, and shipped the interface, useful context stayed attached to the work instead of being lost between disciplines.

MY ROLE

Acted as product designer and frontend engineer: stakeholder interviews, workflow modelling, Figma prototyping, implementation, instrumentation, and A/B testing.

BUSINESS IMPACT

De-risked a cross-product conversion before engineering investment, aligned external and internal stakeholders around a tangible model, then used live evidence to improve the shipped flow.

WHAT THIS SHOWS

Research with implementation accountability; comfort moving between customer conversation, interaction detail, code, and product evidence.