Why we send a video on Friday, not a status report.
A written status report can be 90% true and still completely misleading. A four-minute screen recording of the working build can't. Here's the format we send every week, and the one rule that makes it honest.
The problem with status reports
A status report is a story the team tells about the work. "Authentication: 80% complete." Eighty percent of what? Measured how? The number is a feeling, rendered as a percentage to look like a fact. It can be entirely sincere and still hide that the last 20% is the part that doesn't work.
We've watched projects stay at "on track" for six weeks and then miss the date by a month. Nobody lied. The format just didn't make lying hard enough.
What a demo forces
A recording of the actual product, clicking through the actual flow, cannot round up. Either the button works on camera or it doesn't. Either the data saves or you see the error. The demo is the work, not a description of the work — and the gap between those two things is where most projects quietly fail.
The format
Every Monday, a Loom under four minutes. What went live last week. What's next. What's stuck, said plainly. No slides. No percentages. Just a screen recording and a voice. It takes the engineer who did the work about ten minutes to record.
What it costs us
Nowhere to hide. If a week was slow, the demo is short and we have to say why. That's uncomfortable exactly once — the first time you have to record a thin week. After that it's just the rhythm, and the discomfort does its job: it surfaces trouble while there's still time to fix it.
The one rule
Record the build, not a sandbox. The moment the demo runs on a special branch that only exists for the video, it becomes a status report again — a story about the work. Demo from the same place the client will use it, or don't bother.