Code-First Design: How We Compress 6 Weeks Into 6 Days

Six weeks is the standard timeline a traditional design agency quotes for a product design engagement. Discovery, wireframes, mockups, prototype, feedback, revision. Each phase hands off to the next. Each handoff loses context.

We do it in six days. Not by cutting corners. By cutting phases that produce deliverables instead of decisions.

Where the traditional model wastes its time

Look at a standard six-week design engagement and count how many days a client actually sees something working. In most cases: zero until week four, sometimes week five. The first three weeks produce documents: briefs, user journey maps, wireframes, component inventories. These are artifacts that describe what a product should be. They are not the product.

Discovery sprints, as they are typically run, exist to surface requirements. That is a legitimate goal. The problem is that requirements discovered through conversation and sticky notes are less reliable than requirements discovered by watching a real person interact with a real screen. You do not know what a founder actually wants until they try to use something and tell you what is wrong with it.

Every week that passes before a client sees something interactive is a week where misalignment can compound invisibly. By the time a mockup gets approved and a prototype gets built, the requirements it was based on may already be wrong.

What the Elux Space code-first sprint looks like

Day 1: Brief to working prototype

The brief comes in the day before the sprint starts. We read it, ask the questions that need to be asked, and on day one, we build. Using Claude Code, we prototype the core flows: typically onboarding, the main dashboard, and the primary action the product exists to perform. By end of day, the client has a URL with something clickable.

It is not polished. It does not need to be. The goal is to surface what is wrong before we invest in making it right.

Day 2–3: Real feedback on real screens

The prototype goes into Figma via MCP. The client reviews editable frames of the actual interface, not wireframes representing a hypothetical interface. The feedback we get at this stage is categorically different from feedback on mockups. Founders catch navigation assumptions they never would have noticed in a static design. They realize their user journey is more complex than the brief suggested. They discover that the thing they asked for is not actually what they need.

That discovery happening on day two is worth everything. That same discovery happening on day thirty, after three rounds of mockups and a prototype built from the wrong assumptions, is a project killer.

Day 4–5: Iterate and refine

With concrete feedback on a working product, we iterate fast. Changes go back into Claude Code, the updated interface returns to Figma, and the client reviews again. By day five, the product direction is settled. Not because we ran out of time, but because working through a real interface surface gets you to clarity faster than working through documents about a future interface.

Day 6: Design system and handoff

The final day produces two things: a Figma file with the refined design system the product will be built from, and a handoff document that carries the decisions made during the sprint into the implementation phase. Clean tokens, documented component logic, and a clear rationale for every major design choice.

What clients say when they see this on day one

The consistent reaction is surprise. Not because the prototype is impressive, but because it is real. Most founders who have worked with traditional agencies have sat through week-one presentations of competitor analysis and brand positioning before anyone built anything. Walking into a call on day one and clicking through a working version of their product resets the entire relationship.

One client described it as "the first time I understood what I actually wanted." That is the point. You need something real to react to before you know what you want. Documents do not give you that. Working software does.

Why most agencies can't do this

The constraint is not skill. It is tooling and process. Agencies that built their workflows around Figma-first design have invested years in templates, component libraries, and handoff processes that assume design comes before code. Rebuilding those workflows around Claude Code requires changing not just tools but the entire mental model of what a design agency's job is.

It also requires designers who are comfortable in, or at least adjacent to, a terminal. Not every design team is there. The transition takes time and the willingness to work on real products with imperfect tooling while the workflows are still being figured out.

We started this transition eighteen months ago. The workflows are not perfect. They are faster than anything we did before, and the client outcomes are better. That tradeoff is worth making.

Six weeks was the right answer when you needed all that time. The question now is what you actually need the time for.