Sergi Jajanidze

Sergi Jajanidze

Senior Web Engineer

View selected workDownload resume

Skills

Languages
  • JavaScript,
  • TypeScript,
  • HTML5,
  • CSS3
Frontend
  • React,
  • Next.js,
  • Angular,
  • Lit,
  • Web Components,
  • Tailwind CSS
State & Data
  • Zustand,
  • Redux,
  • GraphQL,
  • TanStack Query
Backend & APIs
  • Node.js,
  • Express,
  • REST APIs,
  • WebSocket
Data & Storage
  • PostgreSQL,
  • MongoDB,
  • Redis,
  • Prisma
Architecture
  • Micro-frontends,
  • Monorepos,
  • Module Federation,
  • SSR,
  • Design Systems
AI & LLM
  • LLM API Integration,
  • RAG,
  • Prompt Engineering
Testing & Quality
  • Vitest,
  • Jest,
  • React Testing Library,
  • Playwright,
  • Core Web Vitals,
  • WCAG
Tooling & DevOps
  • Vite,
  • Webpack,
  • Rsbuild,
  • ESLint,
  • CI/CD,
  • Docker,
  • AWS,
  • Sentry,
  • Grafana

Certifications

Selected Work

Production systems I designed and led — the decisions, the trade-offs, and what I’d do differently.

  1. Consumer bank public site

    LLM-assisted search API

    Added an LLM query-understanding layer in front of an existing keyword index instead of replacing it, so questions and typos resolve to indexed terms — plus a streamed answer card grounded only in pages the index already returned. Every model call falls back to the raw query, so a provider outage degrades to the original search, never to an error.

    ~50%more clicks on search results

    Role
    Lead engineer — sole implementer, backend and frontend
    Scope
    Two endpoints, one shared search component with two consumers, two locales
    Outcome
    50% more clicks on search results
    • Node.js/Express
    • Redis
    • Gemini Flash-Lite
    • Vercel AI SDK
    • Lit 3 web components
    • Module Federation

  2. Internal multi-locale content management system

    Polymer to React/TS CMS migration

    Migrated a daily-use editorial CMS off a dead framework, running old and new apps side by side behind one reverse proxy so editors never saw a freeze. The real work was rewriting a form engine that generates the whole editing UI at runtime from user-defined content types — including multi-locale editing that Polymer had solved with DOM traversal.

    5product teams adopted it

    Role
    Lead engineer — engine owner
    Scope
    TypeScript rewrite of a Polymer 3 app · schema-driven form engine · one deployment serving several sites with their own locale sets
    Outcome
    Adopted across 5 product teams
    • React 18
    • TypeScript
    • Ant Design
    • React Router v6
    • Webpack

  3. High-traffic consumer public site

    Module Federation micro-frontends

    Split a web-component SPA serving two product lines into a shell and two independently deployed remotes, sharing exactly one copy of the framework runtime. Federation emits native ES modules, so remotes load through the browser's own import(), and routes moved to their owning remote one content type at a time.

    3independently deployed apps

    Role
    Lead engineer — architecture owner
    Scope
    A shell host plus two product remotes, each deployed on its own cadence · one import map shared by all three builds
    Outcome
    3 independently deployed apps across 2 teams, with release conflicts between them eliminated
    • Lit 3 web components
    • Webpack 5 Module Federation
    • Native ESM output
    • Import maps

  4. High-traffic consumer public site

    Design system runtime integration

    Moved the design system and framework runtime out of three application bundles and onto a CDN, resolved by the browser from one import map. Webpack externals are derived from that map, so an unresolvable import can't ship, and a design-system upgrade is a version bump in one JSON file rather than a rebuild of three apps.

    ~60%smaller application bundles

    Role
    Lead engineer — designed and built the dependency-resolution layer
    Scope
    One import map — design-system packages, framework runtime and federation entry points — shared by three independently deployed applications
    Outcome
    About 60% smaller application bundles
    • Webpack 5 externals
    • Native import maps
    • Native ESM
    • Lit 3
    • Module Federation

  5. Public web estate · site search

    Trie-based search engine

    Built bilingual full-text search for three public sites as one Node service with a hand-built character trie in memory — no search cluster and no network hop per query. A prefix trie is the crude stemmer an agglutinative language like Georgian needs, and query-time transliteration lets Georgian typed phonetically in Latin find the same pages.

    Role
    Lead engineer — designed the service, wrote the first commit, owned it in production
    Scope
    Three content channels × two languages — one in-memory index per pair, rebuilt daily, with no search cluster to operate
    • Node.js
    • Express
    • worker_threads
    • Hand-built character trie
    • Sitemap ingestion

  6. High-traffic consumer public site

    Prerendering middleware

    Decoupled search visibility from the client-side module graph: an Express middleware detects bots, renders the page in pooled headless Chromium, strips the scripts and returns finished HTML from the same origin and deploy that serves humans. The key decision is forcing the shadow-DOM polyfill before the app loads — otherwise a site built from custom elements serializes to empty tags.

    5public sites with improved search indexing

    Role
    Lead engineer — design, implementation, rollout across sites
    Scope
    One versioned middleware package used by five public sites · configurable crawler list, two cache backends, per-site render settings
    Outcome
    Improved search indexing across 5 public sites
    • Node.js/Express middleware
    • puppeteer-core over CDP
    • Pooled headless Chromium
    • S3-compatible object cache
    • Docker Compose

Side Projects

Things I built on my own time to dig into a specific problem.