Ship weekly, or don't bother measuring progress
If a stakeholder can't see working software every week, you don't have a project — you have a hope.
By Logical
Most projects don't fail at the end. They fail quietly, in the middle, during the long stretch where there's plenty of activity and nothing to actually look at. Reports get written. Tickets move. Everyone is busy. And then, weeks later, the thing that ships is not the thing anyone wanted.
The cheapest insurance against this is also the most boring: ship something real every week.
Why a week
A week is short enough that you can't hide a wrong turn inside it, and long enough to finish something worth showing. Miss the mark on a feature? You've lost days, not a quarter. The feedback loop is tight enough that course corrections are cheap and frequent instead of rare and catastrophic.
Slower cadences feel safer. They aren't. They just move the risk to the end, where it's most expensive to fix.
What "shipped" has to mean
The discipline only works if the bar is honest. Shipped means:
- It runs in an environment someone other than the author can open.
- It does something a real user would recognise as useful.
- It isn't behind a slide explaining what it will do.
A Figma frame is not shipped. A branch that "works on my machine" is not shipped. A demo that only survives the happy path is not shipped. The whole value is in the realness.
Velocity isn't how fast you write code. It's how fast you can be proven wrong.
The side effect nobody mentions
When a team ships weekly, the conversations change. You stop arguing about hypotheticals because you're both looking at the same working thing. Opinions get cheaper; evidence gets cheaper too. Decisions that would have taken a meeting take a glance.
That's the real reason we work this way. Not to look productive — to make being wrong survivable, and being right obvious.