Six weeks is the right amount of time

I have shipped things in a weekend and things in a year. The weekend projects are toys and the year-long projects are compromises. Six weeks is the only length I have found that reliably produces something I still like afterwards.

Why not shorter

A two-week build has no room for the second idea. You have the first idea, you implement it, and you ship it, and the first idea is almost never the good one. The good one shows up in week three, once you have used the thing you made and discovered that the interesting problem was somewhere else entirely.

Why not longer

Past about eight weeks, the cost of cutting something becomes higher than the cost of keeping it. You stop deleting. The project accumulates a sediment of half-finished ideas that nobody will remove because removing them feels like waste. Scope grows to fill the time, and then the time grows to fit the scope, and now it is March.

A deadline is not a constraint on the work. It is a constraint on the deciding.

The shape of the six weeks

Roughly: two weeks to build the thing badly and end-to-end, one week to use it every day and write down what is wrong, two weeks to rebuild the part that was wrong, and one week to finish. The last week is not padding. It is where the empty states get written and the error copy stops saying something went wrong.

The rule that makes it work is that week one produces something you can open. Not a design, not a schema — a running thing with placeholder text in it. Everything you learn after that is real, and everything you plan before it is fiction.