Services
What I take on
Three things, in roughly the order teams ask for them: building the frontend, helping decide how it should be built, and helping hire the people who'll build the rest of it. Looking for a full-time role (40 hrs/week) where I can own the frontend and grow with the product — remote from Tbilisi on EU-timezone hours, and open to contract and consulting work too.
For the commercial side — contract, employer of record, or fixed scope — see how to hire me.
React Engineering
I do my best work when I'm part of the team, not just clearing a ticket queue. That means caring about how the code holds up six months later, not only what gets merged this sprint.
8+ years of React. Strong on component systems and the architecture that keeps a codebase coherent as the team and product grow.
- React, Next.js, Remix.js
- TypeScript & component architecture
- Performance & Core Web Vitals
- Unit, integration & E2E testing
- CI/CD pipelines
Where I pick the work up
At the wireframe and mockup stage, not at the handoff. I prototype the interactions with the product designer, iterate on feedback before anything ships, and stay on the feature through implementation and release. On a three-person team at Channels that meant owning the entire web frontend from design review to continuous deployment.
Legacy code, without a rewrite quarter
Most of the codebases I've joined already had years of decisions in them. I refactor incrementally while still delivering new work — scoping the plan, agreeing it with the people it affects, and shipping it in pieces small enough to review. That's how the UI architecture refactor at Omise ran, on a payments dashboard that stayed in production throughout.
Tests that catch real regressions
Coverage numbers are easy to game; a suite the team trusts enough to gate releases on is not. I write unit, integration, and end-to-end tests (Playwright, Cypress, Jest, Vitest), and I fix flaky ones rather than retrying them — flakiness is what teaches a team to ignore CI.
Performance as a habit, not a project
Core Web Vitals, bundle size, render behaviour, and network waterfalls, tracked while the feature is being built. Small structural things compound: a caching hook for CDN image URLs cut requests product-wide at SiliconMint, and enabling gzip on the API roughly doubled throughput for a one-line config change.
Hiring Support
I help teams hire frontend engineers: resume screens and technical interviews.
- Resume review
- Technical interview participation
Resume screens
Reading frontend resumes for signal rather than keyword bingo — what the candidate actually owned, whether the stack claims hold up, and which of them are worth an hour of your engineers' time.
Technical interviews
Sitting in on interviews as the frontend voice, with questions calibrated to the work the role really involves. Useful when the team hiring a senior frontend engineer doesn't have one yet.
Technical Leadership
Code is the easy part. I also weigh in on architecture, run code reviews that aren't just nitpicks, and help newer devs get up to speed.
- Architecture & tech stack decisions
- Code reviews & quality standards
- Mentoring & onboarding
Deciding before building
The cheapest bugs are the ones designed out. At Omise I agreed API contracts with the backend engineers before implementation started, which cut the rework that otherwise lands on both sides a sprint later. The same instinct applies to stack choices — pick for the team you have and the horizon you're planning for.
Code review as teaching
Reviews that explain the reasoning, not just the diff. I'd rather leave three comments that change how someone approaches the next PR than thirty that get rubber-stamped away.
Maintainer's perspective
I keep react-horizontal-scrolling-menu's public API stable across React 17, 18, and 19, for 20,000+ dependent repositories. Maintaining something you can't break gives you a specific view of API design and versioning that's hard to get inside a single product codebase.
Where you can check this
Sound like a fit? Tell me about the role or project — I usually reply within a day.
How to hire me