Skip to content

Available for remote work

01Artur KhachatryanFrontend Developer

Building complex web products with Vue, Nuxt and TypeScript.

Frontend Developer with 5+ years of commercial experience shipping real-time messengers, CRMs and data-heavy SaaS interfaces. I care about frontend architecture that survives its second year — typed contracts, predictable state, and component systems a team can actually move fast in.

View my work Get in touch Download CV
Experience
5+ years
Core stack
Vue · Nuxt · TypeScript
Focus
SaaS · CRM · Real-time
Location
Armenia — remote
02Selected work

Products where the frontend is the hard part.

Organised by problem space rather than by logo: what each interface had to do, the constraints that made it difficult, and the engineering decisions behind it.

Case 01Real-time communication

Messenger & Communication Platform

A full messaging product — direct conversations, group channels, media galleries and live presence — where every interaction has to feel instant while the underlying socket stream never stops moving.

Frontend developer — client architecture, real-time state layer, message rendering

Problem space

  • Conversation histories long enough that naive rendering stalls the main thread.
  • Messages that are not one shape: text, media, attachments, replies, system events.
  • Media whose height is unknown until it loads, inside a list that must not jump.
  • A socket stream and a REST history that can disagree, reorder or arrive twice.
  • Sending that must feel immediate while the server is still confirming it.
  • Vue 3
  • TypeScript
  • Pinia
  • WebSockets
  • REST API
  • Vite

What I built

  • Implemented virtualized conversation lists so only the visible window mounts, keeping scroll responsive as history grows.
  • Reserved measured space for media before decode to eliminate layout shift and scroll-anchor jumps in the message stream.
  • Built a normalized Pinia store keyed by conversation and message id so socket events, pagination and optimistic writes reconcile into one source of truth.
  • Added optimistic send with server reconciliation and rollback, removing the perceived round-trip on every outgoing message.
  • Reduced re-render overhead by splitting message rendering into memoized, type-dispatched components instead of one branching template.
  • Centralised socket lifecycle — reconnect, resubscribe, replay missed events — behind a composable so views stay declarative.

Engineering detail

Dynamic heights inside a virtualized list

Virtualization wants fixed, known row heights. A messenger has neither: a photo resolves after decode, a text bubble reflows on resize, and users scroll upward into history. The list keeps a measurement cache per message id, seeds it from intrinsic media dimensions so the placeholder is already the right size, and re-measures through a ResizeObserver — patching offsets while pinning the scroll anchor to the message the user is actually reading.

Case 02Internal business software

CRM & Business Management

Operational software for teams that live in it all day: records, pipelines, relations between entities, and permissions that change what every screen is allowed to show.

Frontend developer — data tables, form architecture, permission-aware UI

What I built

  • Implemented server-side pagination, sorting and filtering with URL-synced query state so any view is reloadable and shareable.
  • Built a schema-driven form layer so entity forms are described as typed configuration instead of duplicated markup.
  • Introduced a single permission resolver consumed by guards, menus and field-level rendering, removing scattered role checks from components.
  • Reduced re-render overhead on wide tables by narrowing reactivity to row-level state and memoizing cell formatters.

Forms as typed schema

Every CRM grows dozens of near-identical forms. Describing each entity as a typed field schema — with validators and conditional visibility as data — collapsed them into one renderer, so a new entity is a schema file rather than another 400-line component.

  • Vue 3
  • Nuxt
  • TypeScript
  • Pinia
  • PrimeVue
  • REST API
Case 03Workflow tooling

Business Processes & Automation

Tools that let non-developers assemble their own processes — multi-step approvals, conditional branches and generated forms — configured visually and executed by the platform.

Frontend developer — builder interface, dynamic rendering, state modelling

What I built

  • Modelled process definitions as typed, serialisable structures so the builder, the preview and the runtime renderer read the same contract.
  • Implemented drag-and-drop reordering with transform-only movement and a keyboard fallback for every pointer gesture.
  • Added local draft persistence and dirty-state guards so an interrupted configuration session can be resumed.
  • Isolated validation into pure functions, making invalid branches detectable while editing instead of on submit.

One contract, three consumers

The builder, the read-only preview and the executing runtime all render the same process definition. Making that definition a single typed structure — rather than three interpretations of a loose payload — is what kept the three surfaces from drifting apart.

  • Vue 3
  • TypeScript
  • Pinia
  • Vue Flow
  • Vuetify
  • REST API
Case 04Data-dense product UI

Complex SaaS Dashboards

Analytical surfaces built for density: many simultaneous data sources, cross-filtering, and views that stay legible whether the account has ten records or a hundred thousand.

Frontend developer — data fetching layer, composable views, performance

What I built

  • Standardised data access on TanStack Query with typed keys, so caching, refetching and invalidation are declarative rather than hand-rolled per panel.
  • Debounced and batched filter propagation to collapse cascading widget refetches into a single coordinated update.
  • Moved repeated aggregation out of render into memoized selectors, cutting redundant work on every filter change.
  • Established a shared skeleton, empty and error contract so every widget handles its own states consistently.

Typed query keys as the cache contract

Dashboards fail slowly: each new panel invents its own fetching and the cache becomes unpredictable. Deriving query keys from typed filter objects made cache identity explicit — invalidating one filter dimension updates exactly the panels that depend on it.

  • Vue 3
  • Nuxt
  • TypeScript
  • TanStack Query
  • GraphQL
  • Tailwind CSS
Case 05Adjacent platform work

Telegram Mini Apps & Web3 Interfaces

Frontend work inside Telegram’s WebView runtime — mini apps paired with bots, plus wallet-connected interfaces. Adjacent to my core focus rather than the centre of it.

Frontend developer — WebView-constrained UI, bot-adjacent flows

What I built

  • Adapted layouts to the host viewport and theme parameters so mini apps read as native panels instead of embedded web pages.
  • Wrapped host-client initialisation and wallet interactions in typed composables, keeping platform APIs out of component logic.
  • Modelled pending, rejected and confirmed transaction states explicitly so the UI never presents an unconfirmed action as done.
  • Kept payloads lean through route-level splitting and deliberately minimal dependencies.

Designing for a host you do not control

A mini app runs inside someone else’s chrome: viewport height changes as the keyboard opens, the theme is handed to you, and back navigation belongs to the client. Treating the host as a typed adapter — rather than reading platform globals from components — kept the app testable and portable.

  • Vue 3
  • TypeScript
  • Telegram Mini Apps
  • WebView
  • Web3
  • Vite
Case 06Foundations & shared systems

Other Selected Frontend Work

The work that sits underneath products: shared component libraries, design-token systems, SSR marketing surfaces, and the tooling that keeps a frontend team consistent.

Frontend developer / lead — component systems, SSR, developer experience

What I built

  • Built typed, slot-driven base components with documented props so product teams compose instead of copying.
  • Encoded spacing, colour and typography as tokens, making visual consistency a build-time concern rather than a review comment.
  • Implemented SSR-rendered public pages in Nuxt with per-route metadata and structured data.
  • Tightened developer experience with strict TypeScript, shared linting and conventional project structure to shorten onboarding.

Component libraries fail at the API, not the CSS

Shared components get abandoned when their props grow into a configuration language. Keeping the surface small and typed — slots for structure, tokens for style, variants as a closed union — is what makes a library something teams reach for twice.

  • Nuxt
  • Vue 3
  • TypeScript
  • SCSS
  • Tailwind CSS
  • Quasar
03Experience

Five years moving from building features to owning the frontend.

  1. MVPProject

    Formerly Torro CRM.

    Frontend Developer

    Led frontend work on a CRM and communication platform — real-time messaging, clients and channels, tasks, reports, mailings, and visual business-process automation.

    • Built the real-time messenger surface: dynamic message lists with grouped media, socket-driven synchronisation, and virtualized infinite scrolling that stays smooth as history grows.
    • Solved dynamic media heights inside the virtualized stream — measured placeholders seeded before decode, then re-measured on load, so the list never jumps under the reader.
    • Modelled client-side state so socket events, paginated history and optimistic writes reconcile into one source of truth across messenger, clients and channels.
    • Implemented the visual business-process tooling — nodes, edges, stages, filters and drag-and-drop — over a typed, serialisable process definition shared by the editor and the runtime.
    • Owned frontend architecture across the platform: Vue 3 and Nuxt under strict TypeScript, Pinia beside an inherited Vuex layer, and TanStack Vue Query over REST and GraphQL.
    • Reduced re-render overhead in message and record rendering by replacing branching templates with type-dispatched components, and modernised legacy code without disturbing production.
    • Real-time systems
    • Frontend architecture
    • Business-process tooling
    • CRM / SaaS

  2. Easy Development

    Frontend Developer

    Built and led frontend work on production business applications, owning features from requirement to release.

    • Developed and maintained production-grade frontend applications in Vue 3, Nuxt and TypeScript, owning features end to end — requirements, UI implementation, API integration, testing and delivery.
    • Designed reusable components and frontend solutions for complex business workflows and data-heavy interfaces.
    • Worked across CRM, messaging, clients, channels, tasks, reports, mailings and business-process systems.
    • Integrated REST and GraphQL APIs, and kept complex client-side data flows predictable with Pinia, Vuex and TanStack Vue Query.
    • Developed interactive business-process interfaces with visual nodes, edges, stages, filters and drag-and-drop.
    • Improved frontend architecture and modernised legacy code while keeping production stable, investigating complex UI, browser and cross-platform issues alongside backend, QA and product.

  3. Direlli LLC

    Frontend Developer

    Built and maintained production Vue applications as part of a product team.

    • Developed and maintained production Vue.js applications across Vue 2 and Vue 3.
    • Implemented new features and maintained existing functionality.
    • Integrated REST and GraphQL APIs, working with TypeScript, JavaScript, Vuex and the Composition API.
    • Built reusable UI components and responsive interfaces, including form validation and business logic.
    • Wrote unit tests, investigated production issues, and collaborated with backend developers and QA.

  4. Freelance

    Frontend Developer

    Delivered frontend projects end to end, taking work from requirements to deployed interface.

    • Built websites and web interfaces independently, handling scoping, implementation and delivery.
    • Worked directly with clients to turn loose requirements into concrete frontend scope.
    • Established the JavaScript, CSS and layout fundamentals the rest of my work is built on.
04Engineering

The stack I know deeply, and the tools around it.

Grouped by the job they do rather than listed as a logo wall — because what matters is which layer of a product each one belongs to.

01

Core

The stack I reach for by default and know deeply.

  • Vue 3
  • Nuxt
  • TypeScript
  • JavaScript
02

Markup & Styling

The layer I write by hand — tokens and structure before component libraries.

  • HTML
  • CSS
  • Tailwind CSS
  • SCSS
  • Bootstrap
03

State & Data

Keeping client state predictable and server data honest.

  • Pinia
  • Vuex
  • TanStack Query
  • REST API
  • GraphQL
  • Axios
04

UI & Interaction

Component libraries, form validation, and the primitives behind visual editors.

  • PrimeVue
  • Vuetify
  • Quasar
  • Vue Flow
  • VeeValidate
  • Yup
05

Platform & Runtime

Real-time transport, and the host runtimes a frontend has to live inside.

  • WebSockets
  • PWA
  • Capacitor
  • OneSignal
  • Telegram Mini Apps
  • Telegram Bots
  • WebView
  • Web3
06

Tooling & Quality

The build layer, and the safety net that makes a refactor a non-event.

  • Vite
  • Git
  • Unit Testing

Familiar withReact · React Native— comfortable reading and working in, not where I specialise.

01

Types are the contract

Strict TypeScript at the API boundary means a backend change surfaces as a compile error, not a support ticket.

02

State has one owner

Most frontend bugs are two places disagreeing about the same value. I normalise first and derive everything else.

03

Performance is structural

Smooth interfaces come from render boundaries and reactivity scope, not from adding memoization at the end.

05About

How I think about frontend.

Armenia · Available for remote work

I work on the part of a product people actually touch — and specifically on the products that are hard: real-time messaging, CRMs, process automation, dashboards dense enough that a careless render costs you a frame.

What holds my attention is not the framework of the month. It is the question of why some frontends stay pleasant to work in after three years of feature pressure and others quietly become the reason a team slows down.

Architecture
A frontend is an architecture problem long before it is a styling problem. I spend the early hours of a project on state boundaries, typed API contracts and module structure, because those are the decisions that get expensive to reverse.
Component systems
Reusable components earn their keep through their API, not their appearance. Small typed surfaces, slots for structure, tokens for style — the versions teams keep using are the ones that are hard to misuse.
Performance
I treat performance as a design constraint rather than a cleanup task. Virtualization, reserved space for async content, narrow reactivity: measure the interaction, fix the structure causing it.
Developer experience
Strict types, predictable structure and honest error states are what let a team ship confidently. If a change is scary to make, that is a signal about the codebase, not about the developer.
AI-assisted development
I use AI tooling as part of my workflow — scaffolding, refactors, exploring an unfamiliar API — while keeping the architecture and the review judgement mine. It shortens the distance to a working version; it does not decide what good looks like.
06Contact

Have a complex product to build? Let's talk.

I am open to frontend roles and contract work on ambitious products — particularly SaaS platforms, internal tools and anything real-time. Tell me what you are building and where the frontend gets hard.

Send an email Download CV

Elsewhere

EmailSend an emailGitHubView profileLinkedInView profileTelegramMessage meCurriculum vitaeDownload PDF

07Beyond code

Reading source

Following how the Vue and Nuxt ecosystem solves its own problems — reactivity internals, rendering, build tooling.

Interface craft

Paying attention to how good software feels: motion that clarifies, typography that sets hierarchy, restraint over decoration.

Sharing what I learn

Turning hard-won debugging sessions into things teammates can reuse — patterns, conventions, review notes.