We quote six weeks a lot. It is not a claim about how fast we type. It is a design constraint, and it does most of its work before anyone opens an editor.
The window fixes the scope, not the other way round
The usual sequence is: agree what to build, estimate how long, negotiate. Every part of that is a guess dressed as a plan, and the negotiation always ends with more scope than time.
Fixing the window inverts it. Six weeks is given. The only open question is what fits, and that question has a correct answer you can reason about rather than a number you can haggle over.
A deadline you negotiate is a wish. A deadline you scope against is a tool.
What gets cut, and how
Everything that is not on the value loop. For a product, that is the path from "a user arrives with a problem" to "the product has solved it" — and, if it is a business, to "someone paid". Studio Kanna's prototype had forty screens; nine were on that path.
The cut list is written down with reasons, and it is not a graveyard. It is ordered, and after launch it is the roadmap. Kanna have since shipped four items from theirs, in order.
What we never cut
Three things survive every scope conversation, because removing them costs more than they save:
- Auth and billing done properly. Retrofitting either is more expensive than building it.
- One real integration. A product that does not touch the customer's existing systems is a demo.
- Handover. The documentation and the cut list. Without them, week seven is a support contract nobody agreed to.
When it does not work
Six weeks fails when the problem is genuinely unknown — when nobody can name the value loop because nobody knows what the product is yet. That is a discovery engagement, and pretending it is a build window produces six weeks of confident motion in an unverified direction.
The constraint is useful precisely because it is honest about which of those two you are in.
