Dávid Novák
SK
Case 01 of 05

Designing for trust when people hand real money to an automated system.

PRODUCT
Automated investment platform
ROLE
Frontend Lead, founding frontend engineer, de facto product designer
YEARS
2025–2026
TEAM
Sole frontend engineer, with 3–4 backend and full-stack engineers, a tech lead and a PM
PLATFORM
Web, mobile-first, installable to the home screen
~80%of the codebase, written from the first commit.
Solefrontend engineer and, after taking over from the client’s designer, owner of the product’s UX and UI.
Betashipped to a community of real users, with feedback limited to minor requests.
CONTEXT

An automated investment product. Users hand real money to a system that acts on their behalf, so every screen has to earn their trust.

MY ROLE

The only frontend engineer, working with the founders. I built the whole web application from the first commit and wrote roughly 80% of the codebase. When the initial designs ran out, I took over the design too, and from then on I was solely responsible for the product’s UX and UI.

THE CHALLENGE

Complex concepts, real money at stake, and users who need to feel in control of a system that acts for them.

What I didFive edits to the plan
ATook over the design
THE SETUP

Struck out: Initial designs from an external designer who wasn’t available to carry them further.

MY EDIT

Inserted: I finished and extended his work, then designed every new section myself.

RESULT

I became solely responsible for UX and UI, and the client came to trust my product decisions.

BListened to real users
EXISTING FLOW

Struck out: Relaunching a strategy needs two separate wallet confirmations, and users often miss the second.

MY EDIT

Inserted: A guided dialog with visible, labelled stages and a live status for each, from creating the vault to the deposit landing.

RESULT

More users stayed in the app. I found the problem in the product’s user community.

CA better solution, not a patch
THE BRIEF

Add tooltips to explain the complex features.

MY ADDITION

Inserted: I wrote them, and proposed a knowledge base: 14 articles in 5 sections, searchable from a help button on every page, with info links that open the right article in context.

RESULT

The client accepted it, and I built it.

DPrototyped before building
THE IDEA

Portfolio-history charts with tax events marked on them.

HOW I PITCHED IT

Inserted: A short video prototype, before any production code.

RESULT

Approved. The charts grew into a wider data-visualisation layer.

EPushed back when it mattered
THE REQUEST

Struck out: A live, step-by-step progress view for a background process that takes several minutes.

MY EDIT

Inserted: Postpone it, and ship the higher-priority features first.

RESULT

It didn’t fit the architecture of the time and would have cost a lot. The team shipped what mattered first.

STATES, BY DESIGN
  • Zero balances
  • Insufficient funds
  • Failed or re-submitted actions
  • Partially loaded data

Each was handled deliberately, not left to a default. I also proposed and set up error monitoring, with reports routed through the app’s own domain so ad-blockers don’t drop them. Bugs became faster to reproduce and fix.

OUTCOME

Shipped to a beta community of real users, whose feedback stayed at minor requests. More users stayed after the guided dialog, the knowledge base shipped, and the charts became part of a wider data-visualisation layer.

“He evaluates the client’s request first. If it doesn’t make sense to him, he doesn’t hesitate to point out that it may not be good for the user experience.”
— Fellow engineer
NEXT CASE02 Validator platform suite