Why we ship something you can click every two weeks
Status decks let a project drift for months. A working URL every fortnight makes drift visible in days — here is how we actually run it.
Every failed software project we have been asked to rescue had the same thing in common: for months, the only evidence of progress was a document. A burndown chart. A percentage. A slide that said 70% complete, which meant nothing, because nobody could say what the other 30% was.
So the rule here is simple. Every two weeks, there is a URL. You open it. It does something it did not do a fortnight ago.
Why a fortnight
Shorter than two weeks and you spend more time planning than building. Longer, and the gap between “we think this is going well” and “we know this is going well” grows wide enough for a project to drift without anybody noticing.
Two weeks is roughly the point at which a small team can finish something coherent — not a feature flag behind a login, but a piece of the product a non-technical person can use and react to.
What “working” has to mean
The demo is not a slide. It is not a Figma prototype. It is deployed, on a real URL, with real data, and you can break it while we watch. That last part is the point: the fastest way to find out that a flow makes no sense is to hand it to someone who did not design it.
We also resist the temptation to demo only the happy path. If the error state is ugly, you see the ugly error state. Hiding it just moves the conversation to a worse week.
What this changes for you
Slippage becomes visible in days, not months. If the increment is thin, you can see it is thin. You do not need to interpret a chart or trust a percentage.
Scope conversations happen early. When you can click the thing, you notice the thing is wrong. Week three is a cheap time to find that out. Week nineteen is not.
Nobody can hide. Including us. A team that has to demo every fortnight cannot quietly spend three weeks on an abstraction nobody asked for.
The part that is uncomfortable
It requires you to show up. Fifteen people cannot review an increment; one or two decision-makers can. If the people who can say “no, not like that” are not in the room every fortnight, the cadence does nothing and we are back to decks.
We say this at kickoff, because it is the one thing we need from a client that we cannot supply ourselves.
And when an increment is genuinely bad
Sometimes a fortnight produces very little. A migration turned out to be harder than it looked. An integration partner went quiet. Somebody was ill.
We demo it anyway and say so. A bad increment reported honestly is a project you can still steer. A bad increment dressed up as a good one is how you end up with a rescue engagement eighteen months later — which is, after all, where this whole habit came from.