Your Design Agency Does Discovery Sprints. Mine Ships Day One.

Week one of a traditional design engagement looks like this: stakeholder interviews, competitive analysis, user journey mapping, brand alignment discussion. The output is a document describing what the product should be. Nothing is built. Nothing is clickable. The founder leaves the first week having paid for the agency to understand the problem.

Week one at Elux Space: the client has a working prototype by end of day one. Not a polished one. A real one.

What a discovery sprint actually produces

Discovery sprints have legitimate value in specific contexts. For complex enterprise products with multiple stakeholder groups and regulatory constraints, the alignment work a discovery sprint provides is worth the two weeks it takes. For a seed-stage SaaS product with a founder who knows their market, a discovery sprint is documentation of what the founder already knows.

The deliverable from a discovery sprint, a design brief plus wireframes, describes what a product should be. It does not answer the most important question: does this product, as actually built, do what it is supposed to do? You cannot answer that question with documents. You need something interactive.

What happens when the prototype is day one

The first thing that changes when a working prototype is on the table on day one is the quality of feedback. Founders reviewing wireframes imagine what the product will feel like and give feedback based on that imagination. Founders reviewing a working prototype interact with something real and give feedback based on what they actually experienced.

These are different kinds of feedback. One describes a hypothetical. The other describes an actual problem. The actual problem is fixable immediately. The hypothetical may or may not surface as a problem when the product is eventually built.

The second thing that changes is the discovery timeline. A traditional discovery sprint discovers requirements through interviews and workshops. A code-first sprint discovers requirements through user interaction with a working prototype. The latter is faster and produces more reliable requirements because it surfaces what users actually do rather than what they say they will do.

Why most agencies cannot do this

A day-one working prototype requires Claude Code capability on the team, an MCP-connected workflow for pushing that prototype into a shared review environment, and a design process built around iteration on real interfaces rather than iteration on documents.

Most agencies built their workflows before these tools existed. Their process is optimized for the handoff model: design produces a specification, development implements it. That model made sense when generating a working prototype took weeks. It makes less sense when it takes hours.

The constraint is cultural as much as it is technical. Agencies that built their reputation on thorough discovery processes are not naturally inclined to skip the phase that demonstrates their rigor. Moving to a working-first model requires being willing to look less thorough at the beginning of an engagement in exchange for being more useful throughout it.

What to ask before signing

Two questions that reveal whether a design agency is operating in the old model or the new one. First: when will I see something I can click through? The answer should be measured in days. Second: what does your first week of deliverables include? If the answer is primarily documentation and workshopping, you are looking at the discovery sprint model.

Neither model is universally wrong. The question is whether the model matches your product stage, your timeline, and what you actually need to learn in week one.