One of the things I hear most from the CTOs and founders I work with is that their biggest frustration with designers isn't bad taste — it's the handoff.
They get beautiful Figma files. Pixel-perfect specs. A comprehensive design system. And then the engineering team builds something that looks nothing like what was designed.
It's not malice. It's translation loss. The developer didn't see the hover state. The animation timing wasn't specced. The responsive breakpoint was an assumption. And by the time anyone notices, the sprint is over.
I don't hand off designs. I ship working code.
The Handoff Tax
The traditional design-to-development pipeline has four failure points:
- Specification gaps — things that exist in the designer's head but never make it into the file
- Translation drift — what the developer interprets vs. what the designer intended
- Feedback loops — review → revise → rebuild cycles that eat sprints
- Context loss — the why behind a design decision gets lost somewhere between handoff and implementation
I've experienced all of them. Better specs and better conversations help, but so does keeping the product rationale close to implementation when the role and team structure make that possible.
What Changes When You Build What You Design
When I design a component in Figma and then contribute to its implementation, a few things happen differently.
I catch impossible states before they ship. There's a unique awareness that comes from knowing both how something looks and how it works. When I'm designing a form, I'm already thinking about the loading state, the error state, the empty state, the success animation — not as separate specs, but as code I'm about to write.
Iteration speed changes entirely. Instead of "let me update the mockup, export, write a spec, and hand it off," it's "let me tweak the Tailwind class and see it instantly." The feedback loop collapses from days to seconds.
Design decisions become informed by real constraints. There's nothing like writing the CSS yourself to teach you why that 8-column grid was a bad idea for mobile. The designs that emerge from this process are buildable by default — not because I'm a saint, but because I hit the constraints myself.
A Real Example
On my last project (a B2B SaaS platform for ISP support), I designed and built the site from scratch. The hero section had a specific animation I wanted — subtle, performant, responsive.
In a traditional handoff, I would have spec'd it in Figma with notes about timing and easing curves, then collaborated with an engineer to refine it in the product. In this case, I built it in React during the same session I designed it. The animation stayed close to the original intent because the design and implementation context remained connected.
The result: 0.6-second load time and a 92% accessibility score. Not because I'm a better developer than any front-end engineer — but because there was zero translation loss between what I designed and what shipped.
What This Means for Teams I Join
I'm not advocating that every designer needs to code. Design and engineering are distinct disciplines, and specialization exists for a reason.
What I'm saying is: when you hire me, you're getting someone who closes the loop. I don't produce artifacts that need to be interpreted by someone else. I produce outcomes that go straight into the product.
That means:
- Fewer handoff meetings
- Faster iteration cycles
- Designs that survive contact with reality
- A shared language with your engineering team
I design in Figma because it is useful for exploration. I build in Next.js when it is a good fit for delivery. The goal is to reduce context loss between design and implementation, whether I am contributing directly in code or collaborating with an engineer.
The best UX is the one that ships.