Selected

Portfolio.

The projects that best show what I do and where I'm looking: a working full-stack product and a type-safety experiment across three languages. The booking widget's code is open (links below); Htracker is deployed and running — I'll open access to the demo and the private repository on request. Commercial work is on the homepage, in the Portfolio section.

Htracker — a patient health tracker

Full-stack · FastAPI + PostgreSQL + Vue 3 / TypeScript · deployed

A personal health dashboard I designed and built single-handedly — from the database schema to the interface.

The patient keeps monthly snapshots of their health metrics and the trends across them, records examinations, lab results and consultations with specialists, describes conditions and treatment courses with a timeline, and attaches files (PDF/JPEG/PNG). There's a patient — doctor link: a doctor gets access to the record through an invite flow. There's also a small admin panel for managing the system's users.

The backend is FastAPI and PostgreSQL, built on Domain-Driven Design: eight bounded contexts (Identity, MedicalRecord, Examinations, Analyses, Consultations, Conditions, DoctorAccess, References) with explicit invariants and cross-context links. The frontend is Vue 3 / TypeScript; the frontend types are generated straight from the OpenAPI spec, so the API contract and the client can't drift apart. There's a self-documenting design system on its own page. The project is taken to a working MVP and deployed on my own server (self-hosted Gitea + Docker).

FastAPI PostgreSQL Vue 3 TypeScript DDD OpenAPI design system

Case study

Booking widget — one widget, three type systems

Vue 3 / TypeScript · Effect-TS · Elm · type-safety experiment

A hotel booking widget written three times — to measure how many state errors each type system closes structurally, not "by discipline".

The reference version is Vue 3 + TypeScript (strict): a clean domain, a data layer behind a port-adapter (Dependency Inversion), an atomic-design UI kit, 47 Vitest tests + 4 Playwright E2E. I audited it and found 13 "correctness holes" — places where a type allows an impossible state or a rule rests on a convention. All of them compile under strict.

Then I rewrote the same widget in Effect-TS (TEA + Effect, foldkit) and in Elm and counted how many holes each type system closes structurally (a bad state is unrepresentable) versus "in practice": Effect — 9 of 13 structurally, Elm — 12 of 13, both with 0 left open. The experiment is about the thesis: TypeScript doesn't guarantee a program's correctness after it compiles.

Vue 3 TypeScript Effect-TS Elm TEA type safety

Case study GitHub (Vue+TS) Live demo