Of everything we've tried to keep projects honest, nothing has worked as reliably as a 30-minute demo, every Friday, no exceptions.
It sounds too simple to matter. But most of the dysfunction we see on troubled projects traces back to the same root cause: nobody outside the engineering team saw working software until it was too late to redirect cheaply.
This isn't a status meeting. Nobody talks through slides, nobody reports percent-complete, and nobody is allowed to say "it's basically done" without showing it. If it isn't running in front of the room, it doesn't count as progress yet.
Scope creep hides in silence
A two-week sprint with no visible checkpoint is a two-week bet that everyone agreed on the same thing. They rarely did. The weekly demo forces that disagreement into the open while it still costs an afternoon to fix, not a quarter.
We've watched the same pattern play out on nearly every project that skipped this habit: a stakeholder nods along in planning, engineering builds exactly what was written down, and six weeks later the reaction is "that's not what I meant." Nobody lied. They just never watched it take shape.
If a stakeholder is surprised by what they see in week six, the failure happened in week one — nobody just noticed yet.
The format matters more than you'd think
We keep it to 30 minutes, run it live against a real environment (never slides), and always show what's broken alongside what works. A demo that only shows successes trains stakeholders to distrust the next one.
There's a strict rule against pre-recorded clips or staged data. If the demo environment is having a bad day, that's information too — it tells everyone in the room exactly how close the team is to production-ready, not just how close the happy path is.
What happens when a demo goes wrong
Sometimes the feature isn't ready, or it breaks live in front of the client. That's not a failure of the ritual — it's the ritual working exactly as intended. A broken demo in week three is recoverable. The same gap discovered at final delivery is a crisis.
We've had demos where the only thing to show was a half-working form and an honest "here's what's blocking us." Clients respect that far more than a polished update that turns out to have been hiding the same blocker for a month.
How we actually run it, step by step
Same day, same time, every week — consistency matters more than the specific slot. Engineering drives the walkthrough, not a project manager relaying what engineering did. Whatever shipped that week gets clicked through live, including the rough edges, followed by five minutes for questions and one clear ask: what should change before next Friday.
We run every engagement on a weekly demo rhythm, not a black box.
It changes how engineers build, too
Knowing something has to be demoable in five days changes the shape of the work itself — engineers naturally slice tasks into visible increments instead of disappearing into a two-week rabbit hole.
It's not a silver bullet, and it doesn't replace a real project plan. But it is the single highest-leverage habit we've kept from Zenlor's first year to today.
