Build & Prototype

Code before consensus. Ship working software, iterate on reality.

Build & Prototype

Ship working software in the client's codebase, iterate on reality instead of imagination.

Why This Step Exists

Code before consensus. Working code generates specific, actionable feedback that wireframes can't. "The processing view is too complex" or "the report overview should be the executive summary" — these insights only emerge from seeing real interfaces. Clients reacting to working software make concrete decisions. Clients reacting to sketches make abstract ones.

Every sprint ends with working code in the client's codebase. Production-ready, not demo-ready.

How to Do It

Build the Core Differentiator

Start with the most important screens — the ones that test the sprint's core hypothesis.

  1. Identify the differentiator. Which screen, if it doesn't work, means the sprint fails? Build that first.
  2. Code it at high fidelity. This validates visual direction early — find out at the Scope Lock Workshop, not at the end of the sprint. A wireframe can't test whether "showing 70+ agents feels like serious work is happening."
  3. Prepare the Scope Lock Workshop demo. Frame it as: "This is the visual direction AND the core screens. I focused on the differentiators. Validate before I continue."

Scope Lock Workshop

See Scope Lock Workshop for the full process.

Complete the Locked Scope

After scope is locked in the Scope Lock Workshop, build the remaining screens.

  1. Front-load complexity. Architecture and hard problems early when energy is highest. Polish and refinement later.
  2. Technical freeze before the final build day. If a feature isn't working before the final build day, cut it. No last-minute debugging panic.
  3. Prepare user test. The deliverable isn't just working code — it's working code ready for user testing. Ensure the flow is complete enough for someone to walk through it.

Communication

Async-first. No calls during build days except the Scope Lock Workshop.

  • Daily written updates — Short video (Loom) or written summary. What was built today, what's planned tomorrow.
  • Response time — 48 hours standard for client questions.
  • Quick questions — Telegram/Slack for anything that would block progress.

This protects deep work time. Build days need uninterrupted focus.

Sprint Protection

Rules that prevent the energy collapse pattern. These are non-negotiable during sprint weeks.

  1. 4-hour daily cap. Deep work is capped at 4 hours. At current AI-augmented productivity, this delivers what a traditional designer produces in 3-6 days. Exceeding this leads to 2am finishes — which is a scope failure, not a time failure.
  2. Exercise every sprint morning. Book a personal trainer or external commitment. This creates accountability that can't be cancelled under sprint pressure. Exercise is the cheapest executive function support available.
  3. Front-load complexity. Hardest work early when energy is highest. Polish later. Never attempt complex architecture when energy is lowest.
  4. Technical freeze before the final build day. Not working by then? Cut it. This prevents the last-minute debugging spiral.
  5. Async gap = mandatory rest. Between the build phase and results phase, no sprint work. No admin. No outreach. Recovery.
  6. Cap consecutive build sprints at 2. Never run 3+ build sprints back-to-back. The energy collapse on the first engagement happened at Sprint 3 of 3. A single sprint in isolation may feel sustainable — don't let that fool you into stacking them.

What to Build (and What Not To)

Build:

  • The flow defined in Workshop 1
  • Screens that test the sprint questions
  • Enough fidelity for user testing

Don't build:

  • Features explicitly deferred in the scope lock
  • Admin/settings screens (unless they're the sprint focus)
  • Landing pages (unless Sprint 3 focus)
  • Anything the client hasn't asked for

Over-delivery warning: The instinct to ship more screens than scoped is strong. On the first engagement, 25+ screens were delivered when fewer would have sufficed. The extra work contributed to energy collapse. Build what validates the sprint questions — nothing more.

Locked Decisions

Decision Why
Code before consensus Working code workshops confirmed more productive across all 3 sprints — Research Tech evidence
4-hour daily cap 2am finishes were a scope failure, not a time failure
Front-load complexity Complex components attempted when energy was lowest produced worst outcomes
Technical freeze before final build day Prevents last-minute debugging panic. Cut scope, don't extend time.
Cap at 2 consecutive build sprints Energy collapse happened at Sprint 3 of 3

Research Tech Example

Sprint 1:

  • Built Processing View (core differentiator) and Report Overview at high fidelity
  • Scope Lock Workshop: Demoed to client, received positive validation and two major direction changes (Laminar-style trace view, executive summary as primary screen)
  • Iterated based on Scope Lock Workshop feedback. Delivered 8 complete screens.
  • Over-delivery: Planned 4 priority screens + evidence drawer. Delivered 8 screens with full user journey. This was impressive but contributed to the energy collapse by Sprint 3.

Sprint 2:

  • Workshop 2 on working code was far more productive than sketching. Team reacted to real interactions — decisions were concrete.
  • Built Workflow + Chat screen (core flow) and Evidence Chat based on Supervote priorities.
  • User testing ran with 5 sessions.

Key insight: The feedback on working code in Workshop 2 was qualitatively different from Workshop 1. Clients said things like "the processing view is too complex — switch to a trace view" and "the report overview should be the executive summary, not a collapsible component." These insights only emerge from real interfaces.

Previous: Workshops | Next: User Testing