Why we prototype in code before we polish in Figma

The gap a static frame can’t show

A Figma frame is a perfect moment. Real software is never in one. Data arrives late, lists run long, names overflow and a button gets pressed twice. On the Northwind Labs dashboard, our first review in Figma went smoothly. The first review in the browser surfaced eleven problems in twenty minutes, nine of them about timing and empty states.

None of those problems were visual. They were behavioural, and a frame has no way to show behaviour. A prototype does, even an ugly one.

What we build in week one

In the first sprint we ship a thin, working slice: real routes, real components from our starter kit, and data from a fixture file shaped like the client’s API. It runs on a preview URL from day three. Clients click through it on their own devices and send us screenshots, which tells us more than any presentation.

We keep the styling deliberately plain. Grey boxes, one typeface, system spacing. The goal is to argue about flow, hierarchy and speed while those things are still cheap to change. Motion stays basic too; we tune it later with the curves from Timing curves that feel calm, not clever.

“A frame shows what a screen looks like. A prototype shows what it is like to use.”

Where Figma comes back in

Figma is still where the polish happens. Once the prototype has settled the structure, Amara and Ines pull screenshots of the working build into Figma and design over the top of them. Type, colour, imagery and motion get refined against layouts we already know hold up with real content.

Those decisions flow back into code as tokens, not redlines. Engineering never rebuilds a screen from a picture; it updates variables in a system that already runs.

What it costs, and what it saves

Prototyping first adds about four days to the start of a project. On our last six launches it removed an average of two and a half weeks of late changes, mostly in data-heavy screens. Clients also sign off faster, because they approve something they have already used.

It isn’t right for every brief. A brand site with three pages and no data rarely needs it. For products people open every day, we would rather find the awkward parts in week one than in week ten. If that sounds like your next build, tell us about it.