A prototype sprint isn't a hackathon. It's a deliberate, sequenced week that turns a fuzzy product idea into something a team can put in front of users and stakeholders, and make a real decision from. The output is a realistic prototype, but the actual product is clarity.
Here's how the five days break down, and why the order matters.
Day 1, Understand
The fastest way to waste a sprint is to start building on day one. Day one is for getting the question right: what decision does this prototype need to unblock? Who is it for? What's actually uncertain, and what's already settled? By the end of the day, the team agrees on a single sharp goal and the one or two flows that matter most. Everything else is explicitly out of scope.
Day 2, Structure
Before any screens, I map the interaction model: the states the product moves through, the decisions at each step, the feedback and the failure modes. This is the day that prevents a beautiful demo that breaks the moment real conditions hit it. The artifact is a flow, not a screen, deliberately.
Day 3, Prototype the critical path
Now it gets visual. I build the one path that carries the product's core value, at enough fidelity that it feels real, real copy, real data shapes, real interaction. Not every screen. The critical path, done convincingly, because that's what a test actually exercises.
Fidelity where it matters, nothing where it doesn't. A prototype is an argument, not a product, it only has to be real where the question lives.
Day 4, Pressure-test the ugly paths
This is the day most processes skip, and it's where the value is. I build the states nobody likes to demo: empty, error, partial, loading, low-confidence, the user disagreeing. For AI products especially, this is where the experience is won or lost. By the end of day four, the prototype doesn't just work, it holds together when things go wrong.
Day 5, Validate and decide
The prototype goes in front of real users or stakeholders. Not to admire it, to break it, and to watch where understanding fails. The deliverable isn't the prototype; it's the set of decisions it unlocked: what to build, what to cut, what to rethink, and what's now safe to hand to engineering.
Why five days, and not five weeks
The constraint is the point. A week is long enough to make something real and short enough to force ruthless focus on the question that matters. It also lands before anyone has spent serious engineering budget, which is exactly when a wrong assumption is cheap to fix.
You don't leave a sprint with a finished product. You leave with the uncertainty burned down, the riskiest assumptions tested, and a tangible artifact everyone can point at. That's worth far more than five weeks of debating screens.