The handoff from design to development is where agencies quietly lose money. The design is approved, it goes to the developers, and then come the questions. What is the spacing here? What happens on mobile? Which of these three button styles is the real one? The developer guesses, the design team reviews the build, sends it back, and the cycle repeats. Every loop costs hours, and on a fixed-price project those hours come straight out of margin.
The instinct is to blame the tool or the people. It is rarely either. The cause is almost always the absence of a repeatable workflow. When every project handles design-to-code differently, every project rediscovers the same problems. The fix is an operational playbook: a consistent way of structuring files, handing them off, and converting them to code. This is the workflow we use, and the one we help agencies adopt.
Why the Handoff Breaks
Before the playbook, understand what actually goes wrong, because the fixes follow from it.
Designs are made to communicate a look. Code has to encode behaviour. A static Figma frame shows what a screen looks like at one size, in one state, with placeholder content. The developer has to know what it does at every size, in every state, with real content of varying length. The gap between those two things is where every handoff question lives. What is the hover state? What does this look like with a long product name? What is the breakpoint? If the design does not answer these, the developer guesses, and guesses get reviewed and corrected, which is the rework loop.
So the goal of the playbook is to close that gap before code is written, not after. We covered the developer-facing side of this in the Figma to code handoff. This is the operational version for agencies running it at scale.
Step One: Standardise How Files Are Built
The handoff starts long before the developer sees the file. It starts with how the design is built, and this is where agencies get the biggest return.
Insist that designs are built on a system, not as one-off frames. Defined colour styles, text styles, and spacing values, used consistently. Components for anything that repeats: buttons, cards, inputs, navigation. When a design is built this way, it translates almost directly into code, because the developer is building the same components the designer used. When it is built as loose, hand-placed elements with arbitrary spacing and one-off colours, the developer has to reverse-engineer a system that was never there, and that is slow and error-prone. A design that fights structure produces code that fights maintenance, the same way a design system that fails its developers does.
Make this a standard, not a request per project. The agencies that win here have a file structure their designers follow every time, so developers always receive designs in a shape they can build from.
Step Two: Design the States, Not Just the Screens
The single biggest source of handoff questions is missing states. A screen is not one frame. It is a set of states, and the design has to show them.
Require that the design includes the states that matter: the empty state before there is data, the loading state, the error state, the filled state with realistic content. Require the responsive views, at minimum mobile and desktop, so the developer is not guessing how the layout reflows. Require the interactive states for anything clickable: default, hover, active, disabled.
This feels like more design work, and it is, but it is work that has to happen somewhere. Either the designer decides these states deliberately, or the developer invents them and the team corrects them in review. The first is cheaper and better, because the person who owns the design makes the design decisions. Pushing this upstream is the highest-leverage change most agencies can make to their handoff.
Step Three: Use Real Content Early
Placeholder text hides problems. "Lorem ipsum" is always a tidy length. Real product names, real headlines, and real descriptions are long, short, and awkward, and they break layouts that looked perfect with placeholder text.
Get real or realistic content into the design before handoff wherever possible. At least stress-test the layouts with content at the extremes: the longest plausible heading, the shortest, the product with no image. Designs that only work with perfect placeholder content generate a wave of "what about when..." questions the moment real data lands. Catching that at design time is far cheaper than catching it in a built page under review.
Step Four: Run a Structured Handoff, Not a File Drop
The handoff itself should be an event with a checklist, not a link dropped in a channel.
When design passes to development, the developer should be able to answer a short set of questions from the file alone: Are all the states designed? Are the responsive views present? Is the spacing systematic and readable from the file? Are interactive states defined? Is the content realistic? If any answer is no, the file is not ready, and it goes back before code starts, not after.
This checklist is the cheapest quality gate an agency can run. Five minutes of checking before development begins prevents hours of rework later. Make it a standard step that every project passes through, owned by whoever leads delivery.
A short live handoff helps too. The designer walks the developer through the intent: what matters, what is flexible, what the tricky interactions are. Ten minutes of context prevents a dozen messages over the following week.
Step Five: Build Components, Mirror the Design System
On the development side, the code should mirror the structure of the design. If the design is built on components, the code is built on components, ideally the same set. A button in the design is a button component in the code, reused everywhere, not restyled per screen.
This is what makes the conversion fast and the result maintainable. When the design system and the component library line up, a new screen is mostly assembly of existing pieces, which is quick and consistent. When they diverge, every screen is bespoke, which is slow and drifts out of consistency over time. For agencies building on React, this is the same discipline as building a design system from scratch in React, applied to client work.
Step Six: Review Against the Design, With a Defined Tolerance
The final step is review, and the trap here is endless pixel-nitpicking. Define what "matches the design" means before you start, so review is a check against a standard rather than an open-ended hunt.
Decide the tolerance up front: exact on spacing and colour because those come from the system, sensible on things that naturally vary like real-content line wrapping. Review the build against the designed states, not just the happy path. And keep the review to one structured pass with a consolidated list of fixes, rather than a trickle of individual comments over several days, which is how a one-day review becomes a one-week one.
A Word on Automated Figma-to-Code Tools
Agencies often ask whether a plugin that exports Figma directly to code can replace this workflow. It is worth being clear-eyed about what those tools do and do not solve.
The current generation of export tools has improved, and they can produce a reasonable first pass of static markup for a single frame. What they cannot do is make the decisions the workflow above is built around. They do not know your component structure, they do not know how a layout should reflow on mobile unless every breakpoint was designed, and they do not invent the empty, loading, and error states that were never drawn. They produce code for the happy path of one frame, which is exactly the part that was never the hard part.
So treat these tools as an accelerator inside the workflow, not a replacement for it. They can speed up the initial scaffolding of a well-structured design. They cannot rescue a design that skipped states, used arbitrary spacing, and never considered responsive behaviour. The discipline that produces clean, maintainable code, designing the states, building on a system, mirroring components, is upstream of any export tool, and that is where the margin is won or lost. A tool applied to a disciplined design saves time. The same tool applied to a loose one just generates messy code faster.
What This Buys the Agency
A repeatable design-to-code workflow does three things for an agency's economics.
It protects margin, because the rework loop is where fixed-price projects bleed, and the workflow closes it. It makes delivery predictable, because projects stop hitting the same surprises and start running to a known shape. And it makes the work scalable, because a documented workflow can be run by the team and by partners, rather than living in the heads of one designer and one developer who happen to communicate well.
The tools matter less than agencies think. The agencies that deliver design-to-code profitably are not the ones with the cleverest plugin. They are the ones who turned the handoff into a process that runs the same way every time, so the same problems get solved once instead of on every project.