Live webinar series: Weekly round-tables with industry leaders from product, design & engineering. Sign up →
Try Playground

From Mockups to Merge Requests: Closing the Costliest Gap in Product Development

Lev Kerzhner

The design to production gap exists because product intent lives in design tools while execution lives in code, and every step between them requires human interpretation. That translation introduces delay, inconsistency, and rework. Closing the gap means removing the translation step, not improving it.

Why product teams face this

Most product teams are structured around a sequence of artifacts. A PM defines behavior in a PRD. A designer translates that into screens. An engineer translates those screens into code. Each step is a different system with different constraints.

This structure creates a predictable cost. Every handoff introduces ambiguity. Every ambiguity requires clarification. Every clarification slows delivery or leads to incorrect implementation.

The issue is not individual skill. It is the mismatch between tools. Design tools describe visuals and intent. Codebases define logic, state, and constraints. The two are not directly compatible, so teams rely on people to bridge them.

This shows up in ways product teams recognize immediately. A spacing value is slightly off. A loading state is missing. A component behaves differently than expected. None of these are major failures, but together they compound into weeks of iteration.

From a business perspective, this is where velocity is lost. Engineering time shifts from building to interpreting. Design time shifts from creating to reviewing and correcting. Delivery timelines stretch not because the work is complex, but because alignment is fragile.

How it works in practice

Consider a common feature: a new onboarding flow. The PM defines the steps and edge cases in a document. The designer creates polished screens in Figma, including happy paths and a few states.

When the feature moves to engineering, questions appear immediately. What happens if the API fails? How should validation errors display? Are these components existing or new? Some answers are in the design, others are implied, and many are missing.

The engineer makes reasonable decisions to move forward. They map designs to available components, adjust spacing to match the codebase, and implement interactions based on prior patterns. The result is close, but not exact.

Design review catches differences. Typography is slightly off. A transition feels wrong. An edge case was not handled as intended. Feedback is given, updates are made, and another round of review follows.

Meanwhile, product timelines slip. What looked like a straightforward feature accumulates days of back and forth. None of this work is visible in a roadmap, but it consumes a large share of effort.

This is the design to production gap in action. Not a single failure, but a chain of small translations that degrade intent and slow execution.

What changes when you solve it

Solving the gap changes the workflow structure, not just the tools. Instead of moving from idea to artifact to code, teams move directly from intent to implementation.

The key shift is that design is no longer a static description. It becomes an input that generates real code in the production environment. There is no separate translation step because the output already conforms to the codebase.

This eliminates entire categories of work. There is less need for detailed annotation because behavior is encoded directly. Design QA shrinks because what is reviewed is already production code. Rework drops because there is less interpretation.

The role of the team also shifts. Product managers focus on defining intent clearly. Designers focus on interaction quality and system consistency. Engineers focus on validating, extending, and maintaining the system rather than recreating UI from scratch.

Speed increases, but not because people work faster. It increases because fewer steps exist. The constraint moves from execution capacity to decision making. Teams ship when they are ready, not when implementation catches up.

How Fei Studio approaches this

Fei Studio operates directly in the production codebase and generates code that uses existing components rather than recreating UI. A designer or PM can point to a part of the interface, modify it using natural input, and produce a pull request that aligns with the current system. Because it works against real code and not a separate design artifact, it removes the translation layer that typically causes drift.

Closing

The costliest gap in product development is not between idea and design, but between design and code, and it disappears when intent is executed directly in the codebase.

about the authorLev Kerzhner

Let's book a Demo

Discover what the future of frontend development looks like!