--- title: Interface Engineering: Design to Production React description: Turning a design you believe in into a production build without the quiet compromises that usually happen between the design file and the merged branch. canonical: https://www.hire-web-dev.com/services/interface-engineering/ section: Services updated: 2026-09-11 author: SumanKumar Phuyal site: hire-web-dev.com note: >- Generated from the page of record at the canonical URL above. The four case studies are placeholder work and their metrics were never measured; imagery is AI-generated concept art. See https://www.hire-web-dev.com/disclosure/. --- # INTERFACE ENGINEERING You have a design you believe in. I build it without the quiet compromises that normally happen between a design file and a production branch. ## The problem this solves Designs degrade on the way to production, and rarely because anyone decided they should. A spacing scale gets approximated. A transition that was specified at four hundred milliseconds ends up at the library default of two hundred. An empty state nobody drew gets invented under deadline. Individually each is minor; together they're the difference between a product that feels considered and one that feels assembled. ## How I work through it I start by reading the design for the things it doesn't say, and I come back with a list: what this list looks like with one item, with a thousand, with a failed request, with a forty-character name where eight were drawn. That list is usually the most valuable artefact of the first week, and it's cheaper to answer those questions in a document than in a pull request. Then I build in vertical slices. One complete screen, every state, on real data, before starting the second. It front-loads the unpleasant discoveries — that the API can't provide a field the design depends on, that the interaction needs a value the endpoint doesn't return — while there's still time to respond to them. ## What you get A production frontend with every state implemented, keyboard navigation and screen reader behaviour handled as part of the build rather than retrofitted, and a written record of the decisions made where the design was ambiguous. Plus the list of things I'd still change, which is never empty. ## Key facts - Typical: 6 — 10 weeks - Inputs: Design files, API access - Output: Production frontend - Stack: React / TS, usually ## Fit - Good fit: Settled design, real API - Bad fit: Design not started - Duration: 6 — 10 weeks - Handover: Docs + decision log ## Topics REACT, TYPESCRIPT, STATE MACHINES, ACCESSIBILITY, COMPONENT ARCHITECTURE ## Image ![Array of dark translucent interface panels showing network topology, metrics and status tiles](https://www.hire-web-dev.com/assets/img/interface-engineering-translucent-ui-panels.jpg)