Six-week builds: what actually has to happen

Six weeks to a working system. We've done this dozens of times. It's not a sales line. It's a specific methodology that requires a specific kind of discipline, and it doesn't work if you skip the hard parts.

Week one is not a sprint planning meeting

The first week is embedded research. We get into the client's environment, physically or virtually, and we watch. Where does time actually go? Where does the friction live? What would quietly disappear from someone's day if we got this right?

Most briefs are wrong. Not because clients don't know their own problems, but because they've lived inside them long enough to stop seeing the workarounds as workarounds. Week one is about finding the problem underneath the stated problem.

The narrow door

End of week two, we make a decision that makes most clients uncomfortable: we pick the one thing this system absolutely must do well. Not the five things on the brief. One.

This is the hardest conversation in any engagement. Everyone has a list, and the list feels reasonable. Our job is to make the case that doing one thing excellently beats doing five things adequately, and that the list exists precisely because nobody has been willing to make the call yet.

Scope isn't a constraint. It's a design decision that someone has been postponing.

Weeks three through five: build in the open

Every Friday we share working software. Not a mockup. Not a Figma prototype. Not a video walkthrough of what we're planning to build. A system you can actually open and use. This creates a forcing function that no amount of design review can replicate: if something is wrong, we find out in week three instead of at launch.

Teams that review mockups end up with a system that looks like what they approved. Teams that review working software end up with a system that works the way they actually use it. The gap between those two outcomes is enormous.

Week six is delivery, not deadline

If week six feels like a crunch, something went sideways in week four. The final week is for handover documentation, user testing, and a controlled release to a real subset of users when the client is ready for it.

The measure of a six-week build isn't the demo on Friday. It's whether the system is still running reliably six months later, without us in the loop.