A weekly demo is how you find out whether the software you bought still matches the software being built. Status decks, burn-down charts, and "we are 70% done" do not. If nobody has clicked the thing in the last five working days, you do not have a delivery cadence. You have a reporting cadence.
This is the working rule we put in every SOW: demo against the acceptance list, in the product owner's calendar, on a standing weekday. It sits next to paid discovery (what to build) and how we work (who is in the room).
The Job Is Acceptance, Not Theatre
A useful demo does three things:
- Shows working software on a URL the buyer can open (staging, preview, or a recorded walkthrough of a real build - not a Figma click-through dressed as a release)
- Maps each increment to a SOW line so "done" is testable
- Produces a decision - accept, change request, or park - before the next sprint starts
It is not a highlight reel. If the only path that works is the one you rehearsed, you are still in a spike. Treat that honestly; shipping AI past the demo is the same idea for model features.
What to Show
Show the smallest path a real user would take this week.
- New screens or API endpoints that were in scope
- The integration you said would land, including the boring failure (timeout, empty state, permission denied)
- Anything you claimed was "done" last week that was not, with no spin
Bring the SOW excerpt on screen. Tick the lines. If a line cannot be ticked, say so in the first five minutes - not after twenty minutes of architecture.
Record the session or write three bullets the same day: what shipped, what slipped, what needs a written change. Verbal "looks good" is how disputes start. The SOW should already say acceptance is a checklist, not a vibe.
What to Hide (On Purpose)
Do not spend the hour on:
- Internal refactors that have no user-visible or operational effect (mention them in a sentence if they unblocked next week)
- Tooling debates the buyer cannot decide
- A slide titled "risks" with no owner and no date
- Live coding to "just finish it in the meeting"
Hiding broken paths is different. If checkout fails for a second user, that is the demo. Curating only the happy path trains everyone to be surprised in production.
Who Must Be There
| Seat | Why they cannot skip |
|---|---|
| Product owner (buyer) | The only person who can accept or request change |
| Engineering lead (builder) | Owns the truth of what is on staging |
| Optional: design / domain expert | When the increment is UX or a regulated workflow |
If the buyer's "owner" is an account manager who cannot change scope, you do not have a demo. You have a relay. Startup and enterprise engagements use the same meeting with different wrappers - Slack vs written minutes - but the seats stay the same.
Time-box to 30-45 minutes. A two-hour walkthrough is a sign the increment was too large or the SOW list is a novel.
Cadence That Survives Timezones
Myrafy is based in Noida and overlaps US, UK, EU, and APAC hours. The demo still needs a named slot, not "we'll find a time." Prefer a Tuesday or Thursday so the next working days can absorb a change request.
If a week has no user-visible increment (infra, security questionnaire, waiting on a vendor key), demo the blocker and the date it unblocks. Silence is how retainers turn into fog.
Common Failure Modes
- Demo as PowerPoint - screenshots of localhost with no URL the buyer can retry
- No SOW on screen - then nobody agrees what "done" meant
- The build lead is absent - questions bounce to a coordinator
- Scope changes in chat after the call - if it is not on the change log, it is not in the build
- Skipping a week because "nothing big shipped" - small weeks are when you catch the wrong abstraction
FAQ
Is a recorded loom enough? As a backup when calendars collide, yes. As the default, no. You need a live decision, not a video the owner watches at 11 p.m. without ticking the list.
What if the increment is an API with no UI? Demo with a real client: Postman, a thin internal page, or the consumer service. Payload in, payload out, auth shown. "The endpoint exists" is not a demo.
Do we demo to a steering committee? Steering gets a written summary. The weekly slot is for the people who can change the work. A committee demo without an owner is a status deck with more chairs.
The Bottom Line
What a weekly demo is for is acceptance: working software, a SOW list, and a decision. Hide the theatre. Show the paths that will fail in production. Keep the engineering lead in the room.
If your vendor cannot put a URL on the calendar every week, you are buying a report. Buy a build instead.
Want weekly demos written into the SOW? See how we work, browse services, or contact us for a free estimate.