For the first few years I took on design work, the pipeline was obvious. Figma first, code second. Every single landing page started as a set of frames: desktop, tablet, mobile. The client reviewed the frames. We iterated. Then I coded them. Then everyone realised the code did not look quite like the frames. Then we iterated again.
That pipeline is not broken. It is the industry standard for a reason. It works fine when the project is large, when the design system is mature, and when the developer is not the same person as the designer. It does not work when I am trying to ship a production landing page between 9am and 9pm for a fixed fee.
The three hidden costs of Figma-first work
1. Double rendering
Every design decision has to be made twice: once in Figma, where it is a rectangle, and once in the browser, where it is a real div with real type and real spacing. Those two things never agree on the first pass. The Figma version always looks a little tighter. The browser version always has the accurate line height. Reconciling them is a day of work that the client never sees.
2. The illusion of precision
Figma lets me nudge a shadow by half a pixel, animate a microinteraction, and pick between three fonts that look identical at the preview zoom level. None of that matters on a production page served at a real resolution on a real phone. But it absorbs time, and time is the scarcest thing in a one-day build.
3. Client review friction
A client looking at a Figma frame is not looking at the site. They are looking at an image of the site, at two hundred percent zoom, on desktop, with no mobile truth, no scroll behaviour, no real fonts in some cases. Every decision the client makes against that image is a decision they are going to revise when they see the real thing.
What I do instead
The new workflow is simple. I write the copy in a plain text file. I sketch the section order as a short outline. Then I open the codebase and build the page directly in Next.js, section by section, in the browser.
The client gets a preview URL about two hours in. That preview is the real thing: real type, real spacing, real images, real mobile behaviour, real scroll. Every decision they make is a decision against the artifact that will actually ship, not a picture of it.
I still use Figma occasionally. For a logo exploration, for a quick mood board, for an icon I am designing from scratch. But the page itself is built in the browser, because the browser is where it lives.
When Figma is still the right call
- You are designing for a team that will build the code weeks later
- You need many rounds of stakeholder review with markup and comments
- You are exploring brand direction, not shipping a specific page
- You are working on a design system with many reusable components
“Designing in Figma is like rehearsing a concert on a toy piano. Useful, but not the instrument.”
For a fixed-scope, one-day landing page, the browser is faster, cheaper, and more honest. The client sees the real thing sooner. I ship the real thing sooner. Nobody has to reconcile a Figma frame with production code at six in the evening. It has been the single biggest improvement to my delivery speed in the last two years.