What Shipping Every Week Actually Requires

Every week of a build, the client gets a link. Not a slide, not a status percentage, not a screen recording of something running locally. A link they can open, log into, and use badly on purpose to see what happens.

That sounds like a communication practice. It is really an engineering constraint, and it is a demanding one. Promising working software every week changes how the code has to be structured, which decisions can be postponed, and how much unfinished work anyone is allowed to have in flight.

The constraint is the point

Teams do not drift for dramatic reasons. They drift because the work gets organized in a way that produces nothing usable for a long time, and nobody notices the direction is wrong until there is finally something to look at. Six weeks of invisible progress is six weeks of assumptions nobody tested.

A weekly deadline for something a non-engineer can open forces those assumptions into the open on a short cycle. It also removes the most expensive kind of misunderstanding, the one where a feature is built exactly as specified and the specification was wrong. You find that out on day nine instead of day sixty.

Vertical slices, not layers

The most common way to make weekly delivery impossible is to build in horizontal layers: a week on the database schema, a week on the API, a week on the interface. At the end of each of those weeks there is real progress and nothing to show, because a layer is not a thing a person can use.

The alternative is to take one narrow path all the way through. One record type, one screen, one route, one permission check, saved to a real database, deployed to a real environment. It is less efficient in the abstract. You will touch the same files repeatedly instead of finishing them once. What you get in return is a working system on week one that gets wider every week, rather than a set of parts that become a system at the end, if they fit.

Slicing this way also surfaces integration problems immediately. If the identity provider, the database, and the hosting environment are going to disagree about something, they disagree in week one when it is cheap.

Main has to be deployable at all times

Weekly shipping does not survive a long-lived branch. If a large piece of work sits unmerged for two weeks, the demo either waits for it or excludes it, and both answers break the cadence.

In practice this means a few unglamorous things are not optional:

• Small, frequent merges. Work that lands daily stays close to the main line and rarely produces an ugly merge.
• Unfinished features hidden rather than unmerged. A flag, a role check, or an unlinked route lets incomplete work live in the main branch without being visible to a user.
• Automated checks that run on every merge. The point is not test coverage as a number. The point is that nobody has to manually decide whether the branch is safe to deploy.
• A deploy that is boring. If releasing takes a person an hour and some nerve, it will not happen weekly for long.
• Migrations that run forward cleanly. Schema changes that require a manual step in production are the usual reason a weekly cadence quietly becomes a monthly one.

Decisions get made instead of deferred

The hidden cost of long build cycles is the pile of open questions. What happens to a canceled order that was partially refunded? Can a manager edit a submitted timesheet? Does a deactivated user keep their history? These get written on a list and carried forward because answering them requires someone to actually think, and there is always something more urgent.

A weekly demo does not allow much of that. If the slice you are building this week touches refunds, the refund question has to be answered this week. Sometimes the client has a clear answer. Often they do not, and the right move is to make a defensible default, write down that it was a default, and note what it would cost to reverse. That last part matters. A decision recorded as reversible with an hour of work is very different from one that is baked into the data model.

The discipline is not that every decision is correct. It is that decisions stop accumulating as silent debt.

What it actually costs

Being honest about this matters more than selling it.

• Overhead. Preparing something demonstrable, seeding sensible test data, and writing the short note on what changed takes real hours out of every week.
• Rework. Building thin slices first means you will revisit code you already wrote. That is a genuine cost, paid to avoid a larger one.
• Pressure toward the shallow. A weekly cadence rewards visible progress, which can quietly discourage the unglamorous work with no demo value: indexes, error handling, permissions, backups. That work has to be scheduled deliberately, because the cadence will not ask for it.
• Demand on the client. Weekly delivery only pays off if someone on the other side looks and responds. A review that happens once a month turns the cadence into theater.

When weekly is the wrong idea

There are projects where this cadence does not fit, and forcing it makes the work worse.

• Irreducible chunks. Some work does not slice. A data migration from a legacy system, a platform upgrade, or a rewrite of a pricing engine may have no meaningful halfway state. Trying to demo one produces an illusion of progress.
• Research. When the question is whether an approach is viable at all, the honest weekly output is a finding, not a feature. Pretending otherwise leads to demoing a prototype that was never meant to survive.
• Regulated releases. If every change requires review, validation, or an audit trail, the cost per release is high and the right cadence is set by that process, not by preference.
• Mobile app store review. You can still build weekly, but releases to users go on the platform's schedule, so the weekly artifact is usually a test build rather than a public one.
• No one to receive it. If the stakeholder is genuinely unavailable for a stretch, batching to a cadence they can actually meet is more useful than shipping into silence.

In most of those cases you can keep the underlying discipline and change the rhythm. The deployable main branch and the decided questions are valuable whether the interval is one week or three.

The takeaway

Weekly working software is not a promise that a project will go faster. It is a promise that you will know where it stands, and a set of engineering constraints that make that promise keepable. If a vendor offers a weekly demo without a deployable main branch, without vertical slices, and without a habit of closing open questions, the demo is a performance, and you will find out at the end.