Senior Frontend Engineer
10 years on the web · Vue 3, Nuxt, TypeScript · full-stack — from data to interface
I help teams build interfaces that stay understandable as complexity grows — and that aren’t scary to change.
Clear, scalable, reliable.
I build interfaces that hold up as the product grows. The main principle: less hidden logic, clear states, strict types, predictable behavior. Code like that is easy to read, safe to change and simple to hand off to another developer.
From frontend — to product.
I’ve been building web products for ten years, currently in Vue 3, Nuxt and TypeScript. I can put an interface together from scratch and find my way around a large codebase I didn’t write. When it’s needed, I cover the backend and the deploy too — from the database to a working site.
- Product SPAs from scratch — Vue 3, Nuxt, TypeScript
- Frontend architecture: feature-based / FSD, designed for growth
- Typed data boundaries: Zod, schemas, API adapters
- Design systems and component libraries with Storybook
- Complex interactivity: canvas, maps (Cesium, Mapbox GL), charts
- Functional approach: Effect‑ts, Elm, Haskell
- Deployment and self-hosting: own managed server, Docker, nginx
Htracker — a patient health tracker
A personal health dashboard: monthly snapshots of vitals, examinations and lab results, a patient — doctor link, and a small admin panel. A FastAPI + PostgreSQL backend built on DDD, a Vue 3 frontend. Deployed on my own server.
Booking widget — one widget, three type systems
A hotel booking widget written three times. The base is Vue 3 + TypeScript with 13 “correctness holes”; then the same widget in Effect-TS and Elm — counting how many holes each type system closes structurally.
De Prado — finance in ML as explorable knowledge
An interactive companion to a financial ML book: instead of passive reading — “islands” you can play with and test ideas against. Astro with interactive Elm widgets.
How I design interfaces.
I don’t have a whole methodology — I have a steady direction. I start not with screens but with what they’re built from: what the interface’s units are, what states they can be in, and where the line runs between frontend and backend.
A component is a unit of meaning, not of markup
A component exists not because “we need another block here” but because it owns a specific meaning: a card, a field, a loading state. Then you assemble a screen from understandable building blocks — and the interface stays predictable as it grows.
Thin UI, smart backend
There shouldn’t be much logic in the interface. The domain and business rules live on the backend; the frontend’s job is to honestly render the state and pass on the user’s intent.
A vector, not a dogma
I don’t treat my principles as fixed — they’re still forming. The direction, though, is steady: less implicit state, more explicit boundaries and types, a functional approach where it pays off.
On the craft and where it’s heading.
Short pieces on frontend development: how I work with AI, what I’ve learned about design systems, and how I see the future of the profession.
AI in development — a year on
For almost a year I've been writing code with AI. The main thing I've learned: it multiplies whoever understands what they're doing — and just as fast multiplies whoever doesn't.
A design system that survives to the second project
A design system is easy to start and hard to keep. I've stood several up — and learned almost everything valuable from what didn't work.
The frontend developer in ten years
I think the profession is in for a transformation: the frontend developer becomes a UX/UI engineer who holds the interface and the product in one head. And that future is rather to my liking.
Open to interesting work.
I’m looking for a place where I can own the product end to end — the interfaces and what’s behind them. I’m drawn to complex product problems where architecture, type safety and careful UX matter. Write to me on Telegram or by email — I reply quickly.