Insights · Process
The demo rule
Why we refuse to end a sprint without showing working software.
We have one rule we never break: every two weeks, the client sees working software. Not a slide deck, not a progress percentage — something they can click.
Why demos beat status reports
A status report says "login is 80% done". A demo shows that login works, but the password-reset email lands in spam. The first is comforting; the second is useful. Software projects rarely fail because of one big mistake. They fail because many small misunderstandings pile up unnoticed. A demo puts those misunderstandings on the table while they are still cheap to fix.
How we make it work
- Slice vertically. We build thin end-to-end features — screen, API, database — instead of finishing "the whole backend" first. Something is always demonstrable.
- A permanent staging URL. The demo isn't a show we put on. The client can open the same link on Tuesday and try it on their own phone.
- Record it. A 15-minute screen recording means the people who missed the call still see progress.
- End with a decision. Every demo closes with one question: what should we build next?
When there's nothing to show
Sometimes a sprint is mostly invisible work — a migration, a security upgrade. We still demo: a dashboard of response times before and after, or a rehearsal of the rollback. If we can't demonstrate it at all, that's a sign the work wasn't scoped well, and we say so.