Our product work starts in code now. Figma comes second.

When I tell other designers how we build new products now, I get the same look every time. Half curiosity, half concern.

For most of my career the process looked the same. The problem space lived in Miro. Then came a blank Figma file and weeks of iterating over visual examples before anything real existed. Developers joined once the designs were signed off, and the first time anyone could actually use the product was months in.

That order has flipped for us, and I want to explain why, because it is not about designing less.

The thinking now lives in one place

The biggest shift is where the thinking gets captured. A new product starts in Cursor, with the research, the customer profile and the feature planning sitting together in one workspace. By the time we push the product document to Notion for the client to read and comment on, the model we work with has more context on the project than most co-founders would.

That context is what makes the next step possible. The first version of the product grows straight out of it, as working code. Real data, real navigation, real edge cases, in a browser or on a phone.

Figma comes in once there is something real

Figma enters once there is something to design against. We push the screens from the codebase into Figma, one to one, with proper auto layout and named layers. Then we do the design work we have always done there: hierarchy, typography, spacing, the details that make a product feel considered.

The difference is that we are now refining a working product instead of guessing at one. We see how a flow behaves with real content before we polish it. Problems that used to surface in development, like a form that is far longer than anyone expected, show up on day one.

I still spend a lot of time in Figma. It is just not where the project starts anymore.

What this changes for clients

The practical effect is speed without the usual trade-off in quality. Clients see something they can click within days, which changes the conversation completely. Feedback on a working product is concrete. Feedback on a static mock-up is mostly imagination.

• Decisions get made earlier, because everyone is reacting to the same real thing.
• Less is lost in handover, because design and code are never far apart.
• The design system grows out of components that already exist in code, so it stays in sync with what ships.
• Budgets go further, because fewer rounds are spent redrawing screens that were never going to work.

Where it does not fit

This is not the right order for everything. Brand identity still starts with sketching and exploration, and some product questions are better answered with a quick paper prototype than with code. For a marketing website with a strong visual idea, we often begin in design and build afterwards.

For digital products, though, code first has become our default. It only works because the same senior people do the thinking, the building and the design. Split across separate teams, the context gets lost, and you are back to guessing.

If you are planning a product and want to see what this looks like in practice, our app development page walks through the process step by step.