The first draft of this post was twice as long. The second was half as long. This is the third — and most of what I’ve learned about shipping software in fifteen years lives inside the gap between drafts one and three.
Most software projects fail before any code is written. They fail in the brief. They fail in the kickoff. They fail in the first week, when nobody is brave enough to say what we’re actually doing here, in plain words, with the scope cut.
The two-week constraint
When I quote a two-week build, I’m not promising a small amount of code. I’m promising that we will spend the first two days deciding what we’re actually building, and that I will, gently, refuse to add any feature that wasn’t in those two days.
“A two-week project is not a short project. It’s a project that decided.”
It’s the only honest way I’ve found to keep my own promises.
What gets cut
Most things. Most of the time, the thing that gets cut is the thing the client thought they wanted most when they wrote the brief. That’s a feature, not a bug.
Why two weeks, specifically
Two weeks is long enough to do something real. It’s short enough that nobody — me, the client, the client’s boss — forgets what they agreed to. It’s exactly one full sprint plus a buffer for the things you discover on day three.
Anything longer needs a different shape. Anything shorter is usually a script.
A small caveat
None of this works if you don’t actually finish on Friday. The deadline is the constraint. If the deadline can slip, the constraint isn’t real, and you’re back to building software the slow way.
