Every agency proposal now contains the words "transparent process" and "regular updates". They cost nothing to write, which is why everyone writes them.
A weekly demo is a different thing entirely, and it deserves a harder-edged description than "transparency":
A weekly demo is an option contract. You are buying the right to change your mind while changing your mind is still cheap.
That is a financial instrument, not a courtesy. And like any option, it has a price, an expiry and a payoff you can actually estimate.
The cost-of-change curve
Here is the mechanic that makes it valuable.
Suppose you are having a booking system built and, somewhere in the middle, you realise customers need to book for two people at once, not one.
Week 2, at a demo. The data model has been drafted, nothing depends on it yet. The change is a conversation and a revision: hours.
Week 5, at a demo. The model is built, three screens use it, the API returns it. The change touches the model, the screens, the API and the tests: a few days.
Week 9, at launch. The model, the screens, the API, the admin panel, the confirmation emails, the reminders, the reports and the payment records all assume one person. The change is a small project, and it arrives when everyone has run out of budget and patience.
Same requirement. The only variable is when you found out.
The weekly demo does not make you a better client. It just moves your discoveries left. And because the cost of a change grows with everything built on top of it, moving a discovery three weeks earlier is worth far more than three weeks of work.
Why it exists at all: you cannot audit progress
There is a second, blunter reason, and it applies specifically to buyers who do not read code.
When you commission software, you are buying something you cannot inspect. You cannot tell a codebase that is 60% done from one that is 20% done with an impressive status report. You cannot tell good architecture from bad. The traditional substitutes — a Gantt chart, a percentage complete, a weekly email — are all self-reported by the party with an interest in the number.
A working build you open yourself is the only instrument that converts "trust me" into "look".
This matters more in 2026 than it did in 2022. Output volume has gone up sharply, and the quality of what gets produced has not moved in step — Veracode's testing of over 100 models across 80 coding tasks found them choosing an insecure implementation 45% of the time. More code, faster, with the review burden unchanged. "It is going well" has never been a weaker signal.
What counts as a demo
This is where most "weekly updates" fail, so be specific in the contract.
It must be a build you open. On your device, on your connection, at a URL you have. Not a screen share, not a recording, not a Figma prototype. A screen share is the vendor driving; you cannot take a wrong turn, and wrong turns are the whole point.
It must run on real-ish data. A demo on three perfect seed records hides every problem that only appears with 500 messy ones.
It must include what is broken. A demo that only shows finished things is a sales presentation. The most useful sentence in any demo is "this part does not work yet, here is why."
It must be weekly, on a fixed day. Not "when there is something to show". The whole value is the cadence — a fixed date forces a working state, and a working state every week is what makes the project stoppable at any point.
That last property is worth naming. A project demoed weekly is one you can cancel in week four having lost four weeks. A project revealed at the end is one you can only cancel having lost everything.
The five questions to ask at every demo
Non-technical buyers often sit through demos nodding, because they do not know what to ask. These five work regardless of what is being built.
- "Can I try the thing I would actually do?" Then do it — including doing it wrong. Type the wrong date, skip a field, enter a name with an apostrophe, use the back button. The happy path is always polished. The edges are where the project actually is.
- "What did you learn this week that we did not know last week?" A team that learns nothing is not building; it is transcribing. A good answer names a surprise.
- "What is the riskiest part still ahead, and when do I see it?" Risk should be front-loaded. If the hardest piece is scheduled for the last week, the schedule is a wish.
- "What did you decide without asking me?" There will be dozens, and that is correct — you do not want to approve everything. But hearing them surfaces the one that was actually yours to make.
- "If we stopped today, what would I have?" The answer should get better every week. If it is "nothing usable" in week six, you are not buying increments; you are buying a promise.
Demo theatre, and how to break it
The failure mode is a build that always works because it is always shown the same way.
Break it by taking the mouse. By asking for something unplanned. By looking at the second most important screen instead of the first. By asking what happens on a phone — and then actually opening it on your phone, on mobile data, not on the office WiFi.
A team that welcomes this is a team confident in what it built. A team that deflects it — "let me show you that next week", "that flow is not wired up in this environment" — is telling you something, and you should write down the date.
What to do when a demo goes badly
Nobody writes this part down, so the usual response is to say "great, thanks" and worry privately for three weeks. A graduated response is better, and it starts much earlier than most clients think it should.
One bad demo — ask for the reason, not the fix. Things slip. What matters is whether the team can say why in one sentence. "The payment integration returned a format we did not expect and we lost two days" is a project running normally. "We had some issues" is not an answer, and the right move is to ask again, once, politely.
Two in a row — ask what would have to be true to hit the date. Not "will you hit the date", which invites reassurance. This question forces the constraint into the open: more people, less scope, or a later date. There is no fourth option, and hearing which one they pick tells you what kind of team you hired.
Three in a row — cut scope, do not add time. This is the decision clients avoid and it is almost always right. Something has to come out. A build that was rescued for us under NDA only launched because an honest look at the remaining work — about eight months against a client who had roughly one — led to scope being cut to what launch actually required, with everything else moved to a post-launch backlog. That conversation was possible in week one. It would have been a post-mortem in week twenty.
A demo that is a screen share instead of a build — treat it as a red flag immediately. It is the cheapest possible way to look like progress, and the reason a vendor switches to it is almost never neutral.
The general principle: the demo is an early-warning system, and an early warning you decline to act on is just a record that you were told.
Why we tie money to it
We publish four guarantees and they only work as a set: no lock-in, you own everything · no middlemen, direct to the builders · fixed quote, no scope creep · weekly working demos.
The demo is the one that makes the other three enforceable. It is why the payment split is 50% to start and 50% when it is live and you are happy — you have seen a working build every week before the second payment is due, so the balance is paid against evidence rather than against a claim. And it is why we can say that if we cannot get it right, you do not pay the balance: a promise like that is only honest if you have had the chance to object every week rather than once at the end.
It is also the mechanism behind the most valuable thing we do for clients, which is disagreeing with them early. One of our five commitments is that we will not praise a weak idea to get a signature. That commitment is worthless without a weekly forum in which to exercise it.
What it looks like when it works
The clearest example in our own work is a marketplace we were brought in to rescue under NDA. The honest estimate for the remaining scope was about eight months. The client had roughly one.
What made a launch possible was not speed. It was a decision taken at the start, in the open: audit what existed, keep what worked, and cut the scope to what launch actually required, with everything else moved to a post-launch backlog. Geo-matching, booking with online payments, provider onboarding, disputes and request webhooks shipped in about a month; the rest waited.
That conversation only happens if someone is looking at the real state of the work early enough to have it. A project reviewed at the end has no version of that meeting — it has a missed deadline and an argument.
The same habit runs the other way too. When Bronjoy's scheduler was OOM-killed in production — per-minute commands each forking a roughly 200 MB PHP process, overlapping inside a 512 MB container, with every killed run leaving a 24-hour lock behind — we wrote it into the case study rather than out of it. Teams that hide their failures internally hide them from clients too.
Our process is a short discovery call, a written plan with a fixed price and a date within about 48 hours, then a kickoff and a working demo every Friday until launch.
Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.
Frequently asked questions
Is a weekly demo not just extra meetings?
Fifteen to thirty minutes a week, and it replaces the status emails and the "just checking in" calls rather than adding to them. If your demos are running an hour, they have turned into presentations.
What if I do not know what to look for?
Use the five questions above. They require no technical knowledge and they surface the things that matter: unknowns, risk order, decisions taken on your behalf, and what you would have if you stopped.
Does this work on a very small project?
Yes, and it is even simpler. On a three-to-five-day landing page, "weekly" in practice means you see it once mid-build and once before launch — which is still two chances to redirect it instead of none.
What if the demo shows something I hate?
Then it has done its job, in the cheapest week available. That is the payoff on the option. Every plan we sell includes revision rounds for exactly this reason, and the revisions are dramatically cheaper when they arrive in week two.
How do I put this in a contract?
Three sentences: a working build at a URL the client can open, on a fixed day each week, with the client's sign-off recorded against each milestone before the next payment. If a vendor will not agree to that, you have learned what their process really is before you have paid them anything.
