TRVL Code builds high-impact B2C travel websites, hotel and partner dashboards, and next-generation booking interfaces used every day by travelers, hotel owners, and travel professionals.

We are looking for a UI engineer, not a design executor: someone who reproduces a design reference to the pixel, and who — when the reference is incomplete, inconsistent, or not there yet — understands the business well enough to build the right thing anyway.

The problem this role solves

In real product work, the design is rarely finished when development starts. Some screens have a polished Figma. Some have a reference from another page. Some have a look-and-feel and a business goal, and nothing else. And some Figmas contain mistakes: a 17px gap next to a 16px one, an off-token color, a missing hover state, a flow that breaks on mobile.

We have seen three failure modes, and we are hiring against all of them:

1. The blocked developer — stops and waits every time a state, breakpoint, or component is not drawn.
2. The photocopier — reproduces the mockup's mistakes faithfully because "that's what the Figma says."
3. The delegator — treats a backend problem as permission to stop. The API is down, an endpoint is missing, a field is not in the payload — so the ticket sits "waiting for backend," or worse, the design gets quietly reshaped around the gap.

We need the profile that does none of these: fidelity by default, judgment when it matters, always moving, and never silent.

 What "pixel-perfect" means at TRVL Code

• When a finished design exists, you deliver it 1:1 — spacing, typography, color tokens, radii, shadows, motion. No "close enough."
• A design is a reference, not a contract. You notice inconsistencies and resolve them according to the design system, then flag what you changed and why.
• You never replicate an obvious defect. A broken alignment in Figma is a bug to fix, not a spec to honor.
• You never deviate silently. Improvements are proposed and documented, not smuggled in.

 Non-blocking by design

"Waiting for design" is not a status we accept on this team. When something is missing, you derive it and keep moving:

• Loading, empty, error, and success states nobody drew
• The tablet breakpoint that exists only on desktop and mobile
• The RTL (Arabic) mirror, the dark-mode variant, the French or Russian string that is 40% longer
• A component that exists in the design system but not on this specific page
• A screen sales needs to demo next week, with no business analysis and no design yet — assembled from existing components and fake data, clickable, and looking like the real product

You build it from the existing look-and-feel, ship it for review, and continue. Design questions are raised in batches with a proposed answer attached — not one at a time as blockers.

 When the API is not ready — or not right

The API is not responding. An endpoint does not exist yet. The design needs a field the payload does not return. None of these is a reason to stop, and none of them is a reason to change the design. The sequence we expect:

1. Confirm, in writing, with backend — is something missing in the API, or is the design asking for data that cannot exist? Name it precisely so the right ticket lands on the right side. This takes minutes, not days.
2. Mock and deliver. Build the complete, pixel-perfect UI against typed mocks or fixtures — every state included — exactly as if the API were live. The frontend is done and reviewable before the endpoint exists.
3. Integrate when ready. Swapping mock for API should be a contract change, not a rebuild.

Two rules that follow from this:

• The design is never downgraded because the API does not cover it yet. Missing field → the UI is built for the field and backend gets a ticket. Design asking for the impossible → you say so, with a proposed alternative, and it gets changed on purpose — not silently reshaped around the gap.
• There is always a way to move the UI forward. Looking for a reason not to is the one behaviour this team does not accept.

 Business understanding

You know what the screen is for before you write the first line: a booking funnel converts, a hotel-owner dashboard gets scanned in ten seconds, a marketplace listing has to earn trust. That understanding shapes hierarchy, density, and interaction — and it is how you fill the gaps a mockup leaves.

 Mobile-first, responsive, adaptive, and dedicated mobile

Mobile is not an afterthought and not "desktop squeezed into 375px."

• Mobile-first: you design and code from mobile constraints up, not desktop down.
• Responsive: fluid grids, relative units, container queries, layouts that flow at any width.
• Adaptive: you know when a breakpoint needs a different layout or component behavior, not just a reflow.
• Dedicated mobile: for some B2C pages, responsive is not enough — different navigation, different content hierarchy, different interactions. You know when that is the case and can propose and deliver a mobile flow that feels native.

If these distinctions are new to you, this role is not the right fit.

 Our real constraints (this is not a generic frontend job)

• RTL is a first-class citizen. Arabic is a core market. Logical CSS properties, mirrored layouts, bidirectional text — from day one, not as a patch.
• Dark mode is a default, not a theme bolted on later.
• Four languages (EN / FR / AR / RU) with text-length variance that will break lazy layouts.
• Every component is verified in a four-cell matrix: light×LTR, dark×LTR, light×RTL, dark×RTL.
• Design system first: components live in Storybook and are reused across products. You contribute to the system, not around it.
• Performance and accessibility are budgets, not aspirations: Core Web Vitals, bundle-size limits, WCAG 2.2 AA.

 AI: you are the pilot

We expect you to use AI coding assistants every day, and to be faster and better because of it. We also expect you to remain the engineer in charge.

AI-piloted (what we want)

• You read, understand, and can defend every line that ships — generated or not.
• You use AI to accelerate scaffolding, refactors, tests, and exploration, then apply your own CSS and design judgment on top.
• Your output stays consistent with the design system and codebase conventions regardless of how it was produced.

AI-driven (what we reject)

• Code you cannot explain in review.
• Duplicated components, inconsistent naming, off-system styling, or generic "AI-look" UI because that is what the tool produced.
• "The AI did it" as an answer to why something is wrong.

We check for this in the practical test and in code review.

 What you will do

• Turn design references into pixel-perfect, production-grade interfaces — and complete what the reference leaves out
• Build mobile-first B2C experiences: responsive, adaptive, and dedicated mobile layouts where warranted
• Implement custom UI patterns, transitions, and micro-interactions (GSAP or equivalent) with restraint and purpose
• Build and extend the design-system component library in Storybook; keep visual consistency across products
• Ensure flawless rendering across Chrome, Safari, Firefox, Edge, iOS, and Android — including RTL and dark mode
• Integrate REST APIs and handle real data states (loading, empty, error, partial)
• Own visual quality: review your own work against the reference before anyone else does
• Work with designers as a peer: elevate their work, propose alternatives, document decisions

 Required technical skills

• Expert in React, Next.js (App Router; SSR / SSG / ISR), TypeScript, HTML5, CSS3
• Deep CSS mastery — not framework-only: Grid, Flexbox, logical properties, container queries, custom properties, cascade layers, typography and spacing systems, animation performance
• Tailwind CSS plus experience with a component library (MUI / Base UI / shadcn-style primitives) and custom component styling
• Storybook-driven component development
• Internationalization and RTL implementation experience
• Cross-browser and cross-device debugging, pixel-level fixes
• REST API integration, including working ahead of the API with typed mocks and fixtures (MSW or equivalent) so the mock-to-live swap is a contract change only
• Git discipline; testing fundamentals (unit and visual regression)
• Working knowledge of SEO, Core Web Vitals, and accessibility (WCAG 2.2)

 Design and product skills

• Sharp eye for hierarchy, spacing, rhythm, alignment, and typography — you spot a 1px drift on sight
• Ability to derive missing screens and states from an existing look-and-feel
• Ability to challenge a design constructively and propose a better UX with reasons
• Empathy for the end user: the traveler on a slow phone, the hotel owner scanning a dashboard, the Arabic reader on a mirrored layout
• Understanding that conversion-oriented UI and dashboard UI are different disciplines

 Personal qualities

• Perfectionist by temperament, pragmatic in delivery: fast and precise, not one or the other
• Autonomous — unblocks yourself first, then informs; does not wait to be told
• Treats a blocker as a ticket to open and a mock to write, never as a reason to stop or to hand the problem to another team
• Proud of your work and uncomfortable shipping something that looks off
• Organized, reliable, and respectful of workflow, design system, and code review standards
• Clear communicator: documents what was changed versus the reference and why

 Do not apply if

• You only execute designs and never notice or fix what is wrong in them
• You stop working when a state, breakpoint, or screen has not been designed yet
• You treat a missing, broken, or incomplete API as a reason to stop, or you reshape the design around a backend gap without saying so
• You look for arguments not to do the work instead of the way to do it
• Your CSS depth stops at utility classes or a component library
• You ship AI-generated code you have not read or cannot explain
• You have never shipped RTL or dark-mode UI and are not eager to learn it fast
• You want part-time, freelance, or parallel commitments
• You cannot follow workflow, design system, or code review standards