What a weekly demo actually costs us

Every project we run has a demo on Friday. Not a status email, not a board someone might open. A working build on a staging URL, and forty minutes on a call where the client clicks through it themselves.

People assume this is a nice touch. It is not. It is the most expensive habit we have, and it is the reason our projects land.

The cost

A Friday demo means Thursday is not a build day. Someone has to get the branch into a state where a person who has never seen the code can click five things without hitting a stack trace. That is seed data, that is a deploy, that is half an hour of someone walking the flow themselves first so the client does not find the broken button before we do.

Across a twelve week build that is close to two weeks of engineering time spent on something that ships no features.

We still do it, because the alternative costs more.

What it buys

The expensive mistakes on a software project are not bugs. They are agreements.

Someone said "search" in a kickoff call and meant filtering by three fields. The engineer heard full text search across every record with fuzzy matching. Both people walked away satisfied. Nobody finds out until week nine.

A demo finds that in week two. The client sees a filter panel, says "oh, I meant I want to type a name and find the person", and we lose an afternoon instead of a sprint.

We have never had a project where the scope signed in week one survived contact with the client's own screen. Not once. The scope is a hypothesis. The demo is the test.

The uncomfortable part

Weekly demos mean showing work you are not proud of. Week three usually looks bad. Buttons in the wrong place, placeholder copy, a table with no sorting yet.

There is a real pull toward hiding that until it looks better. Every agency feels it. The instinct is to show a polished thing in week eight and collect the applause.

The problem is that applause is worthless and week eight is too late to move anything structural. So we show the ugly version, we say out loud that it is the ugly version, and we get the feedback while it is still cheap to act on.

Clients who have worked with agencies before find this jarring for about two weeks. Then they relax, because for the first time they can see what they are paying for while they are paying for it.

What it does to the estimate

A side effect we did not expect: our estimates got better.

When you have to produce something clickable every week, you cannot hide a hard problem in the middle of a sprint and hope it resolves itself. It shows up as a week where the demo does not move much, and you have to say why. That conversation happens ten times over a build instead of once at the end, and by the fourth or fifth one both sides have a realistic sense of the pace.

We now price fixed after the plan phase rather than after the kickoff call, because a week of documenting architecture plus a habit of weekly proof means we are guessing about far less.

Fridays, not launch day

Course corrections happen on Fridays. That is the actual promise. Not that we get it right the first time, because nobody does. The promise is that the gap between a wrong assumption and someone catching it is never longer than five working days.

Launch day should be boring. If the client is surprised by anything on launch day, we did the previous twelve weeks wrong.