Fullstack Engineer
17 years on the web · Vue 3, TypeScript · Node.js, Python, PostgreSQL · deploy and operations
I take a product direction and carry it through to users. Code gets written fast now — I’ve built my development process around AI tools, and the “idea → production” cycle is measured in days. The scarce part hasn’t been typing code for a while: it’s who decides what to build, holds the whole context and answers for it working in production.
Build an MVP
The first version in front of users — not a throwaway prototype but a working product with metrics that show whether it took off. After that we fix things by feedback, until the hypothesis becomes a product or gets closed.
A new direction in the product
The company wants to probe an adjacent segment or market. I assemble a separate branch of the product without breaking the main one and take it to launch — so it can either grow into a full line or be shut down painlessly.
Extend the product line
A second and a third product join the first. Everything shared — auth, billing, the design system, deploy, monitoring — I move into a reusable layer, so each next product costs less than the previous one instead of repeating the whole build.
Automation
Processes held together by people and spreadsheets: admin panels, internal tools, integrations between services, recurring exports and reports. Unglamorous work that frees up expensive team time and removes manual-entry errors.
Clear, scalable, reliable.
I write code that holds 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.
Both halves of the app.
The main depth is product interfaces in Vue 3 and TypeScript: commercial platforms from scratch, canvas and 3D maps, a form builder with conditional branching, design systems, corporate SSO. The backend runs on two lines: Node.js with Effect‑TS and DDD, and Python with FastAPI. I’m not tied to a language — my projects have backends in TypeScript, Python and Rust, and I pick the tool for the job.
- Product SPAs from scratch — Vue 3, TypeScript, FSD with boundaries enforced by the linter
- Backend: Node.js (Effect‑TS, DDD) and Python (FastAPI, SQLAlchemy async, Alembic)
- API contract before code: OpenAPI as the source of truth, frontend types generated from the spec
- PostgreSQL: schema, migrations, a domain model split into bounded contexts
- Complex interactivity: canvas, maps (Cesium, Mapbox GL), charts
- Design systems and component libraries with Storybook
- Operations: my own server, Docker, nginx, CI/CD, Prometheus + Grafana
- Tests: Playwright e2e on top of everything, pytest and node:test on the backend
Ege.plus — an education portal
A large production project: built, maintained and evolved. The portal is part of the site-and-service ecosystem of “National Education” — the publisher of a popular prep book for the Russian state exam. For ege.plus I built the entire frontend (Vue 3 + TypeScript + Pinia, with a Redux store as an experiment), along with Storybook and a design system.
In production the site is wired to Sentry: errors show up in real time, which made working with the QA team much easier. More than that — the system shows every user interaction on the site, and some bugs surfaced before QA ever noticed them.
The “National Education” ecosystem
Other projects for the publisher were smaller but no less important: landing pages, legacy React sites, the shopping cart in the catalog, corporate SSO integration. The full range of work on the visual side of the ecosystem. I would have liked more business metrics from the product team — all we had was Yandex Metrica.
Projects under NDA
I’ve worked on many projects, mostly in Vue. One of the recent ones — a system for analyzing economic indicators for the economics department of a large company: lots of widgets, charts and tables, a lot of data on one page. A UI library of 100+ elements, a serious Python backend. On the same project I worked with maps: object markers and extra per-object details in modals.
Htracker — a patient health tracker
My own full-stack projects I build for myself and for friends; several run in production.
The problem. A person’s medical history is scattered across paper: certificates, reports, lab results. As long as it’s paper, you can’t do anything with it. It needs to be gathered in one place, turned into data, so treatment becomes a process with visible progress — and you come to the doctor with that base for a substantive conversation.
The decisions. Model boundaries: examinations, lab results, consultations, conditions and treatment courses, doctor access — independent contexts with their own rules (DDD). The key product decision — “condition” and “treatment course” as entities with a timeline that records attach to. A stack picked for the job:
- logic — Python FastAPI + PostgreSQL,
- frontend — Vue 3 + TypeScript, frontend types from OpenAPI,
- e2e tests in Playwright,
- deploy — Docker + nginx + CI/CD on my own server.
How it’s built. The backend is cut into eight bounded contexts (Identity, MedicalRecord, Examinations, Analyses, Consultations, Conditions, DoctorAccess, References), each with four layers: domain — aggregates and invariants without a single framework import, application — use cases, infrastructure — SQLAlchemy and repositories, api — the HTTP wrapping. Dependencies point strictly one way, and contexts talk only through a neighbor’s application layer — so each context stays independently bootable.
The frontend — Vue 3 / TypeScript with Feature-Sliced Design: the frontend mirror of the same rule, “modules connect only through public entry points”. Frontend types are generated from the OpenAPI spec, so the API contract and the client physically cannot drift apart. Auth — JWT in an httpOnly cookie with a silent refresh on 401. There’s a self-documenting design-system page.
The code is on GitHub, the site runs on my server — access on request.
Booking widget — one widget, three type systems
A hotel room booking widget: date selection in a calendar, matching a room to the number of guests, availability for the chosen dates, night and price calculation, language (ru/en) and theme switching, and a “select → review → confirm” flow.
I built the base version in Vue 3 + TypeScript in strict mode, then wrote two more — in Effect-TS and in Elm. The compiler closed more than ten correctness holes that TypeScript let through.
| Slice | Vue 3 + TS (base) | Effect-TS / foldkit | Elm |
|---|---|---|---|
| Holes closed structurally | — (reference, 13 open) | 9 of 13 | 12 of 13 |
| Closed “in practice” | — | 4 | 1 |
| Left open | 13 | 0 | 0 |
| Impossible states | Date | null × 2 fields are independent; the status flag is detached from validity | sum types; Reviewing/Confirmed carry ValidBooking (smart constructor) | the same + an opaque BookableDate: a past date can’t be constructed |
| I/O boundary | as RoomDto[], as RoomId — checking is off | Schema is the domain type: decoder and type can’t diverge | Json.Decode: bad input doesn’t reach the domain |
| Dates | local getMonth/Date, risk of an off-by-one by TZ | CalendarDate — a day without time or zone | justinmimbs/date — a day without time or zone |
| Errors | confirm() does no effect, can’t fail | a typed channel catchTags → exhaustive messages | the ADT SubmitError (409 → RoomTaken), a message per cause |
| Exhaustiveness | ternaries locale === 'ru' ? … silently swallow a 3rd locale | Match.exhaustive — a new locale breaks compilation | case over Locale — same |
| Tests | 47 Vitest + 4 Playwright | 32 (Story/Scene + property-based on fast-check) | 77 elm-test (unit / fuzz / update histories) |
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 team that needs someone they can hand a whole direction to — an MVP, a new product line, an automation — and get a working result rather than a status report. I’m drawn to problems where architecture, type safety and careful UX matter. Write to me on Telegram or by email — I reply quickly.