The Website Is Finished. It Has Been Finished for Seven Weeks.

An illustrative scenario examining a delivery failure mode. The people, project and ledger below are hypothetical, not a reported client engagement.

At 09:02 on the seventh Tuesday, the account director opens the same staging link. Twelve pages. One contact form. Four comments in the review tool. Beside the keyboard, a paper cup has dried into a brown ring around the words “final approval.” The project board says ninety-eight percent complete. It said ninety-eight percent complete before the designer went on leave and after the designer came back.

A finished site still waiting to launch? See how we investigate it →

The homepage fills the screen. The client likes it. The agency likes it. The developer has already moved to another build. In the weekly status email, the launch date has been replaced by “awaiting final items.” This is the sixth version of that sentence. The website itself has changed less.

One item asks for a mobile heading to wrap differently. One asks who receives the contact form. One requests a replacement team photograph. The fourth says “check redirects,” which is a task approximately as bounded as “check building.”

There are only a few things left.

The explanation is reasonable. A launch puts a client’s name on a public system. The agency should check where enquiries go. It should account for the old URLs. It should not deploy a photograph the client has asked to replace. Nobody wants to explain why a rushed release sent prospective customers into an unattended inbox.

The owner has spent years earning the kind of trust that allows a client to send a concern on Friday afternoon and expect someone to care about it on Monday morning. Holding the release while the last details settle feels like an extension of that responsibility.

A new statement of work for four comments would look disproportionate. Reassembling the whole project team would cost more than the fixes. The sensible course is to stay responsive, collect the remaining answers and finish quietly.

You are protecting the client relationship.

Another dashboard will not approve the photograph.

The agency does not need a lecture about project management. There is a project manager. There is a board. There are coloured labels, named assignees and a recording of the last meeting. A second system would faithfully reproduce the first system’s unanswered question about the form.

Nor does this automatically justify a new developer, a new CMS or a migration. A capable developer can be unavailable because the agency reasonably scheduled the next job. A client can be slow to approve a photograph because the person in it has left. Those are ordinary conditions of delivery.

The team needs room to accommodate them. An agency that treats every incomplete answer as a contractual dispute will struggle to remain an agency anyone wants to hire.

But accommodation needs a record of what it is accommodating. Otherwise a mobile defect, an optional image change and an unresolved business decision sit in the same list, each with equal power to stop the release.

Ninety-eight percent has a weekly cost.

Take a deliberately small ledger. Each week, the account director spends thirty minutes preparing an update, the developer spends thirty minutes reopening the work, and both attend a thirty-minute status call. That is two staff-hours before a fix is made. A further hour of retesting brings the total to three.

Twenty-one hours will not sink the agency. That is partly why the work survives. No individual entry is large enough to demand a decision. Across five comparable stalled projects, the same assumptions produce 105 hours of holding work. The production schedule contains five nearly finished websites and more than two full forty-hour weeks spent keeping them nearly finished.

If final payment depends on launch, cash collection also waits. The payment has not necessarily been lost. It has acquired an administrative waiting room.

The client has not signed off.

There is ample evidence for this explanation. The replacement photograph has not arrived. The marketing manager forwarded the preview to another director. IT has not answered the access request. A supplier has offered a deployment window next Thursday, provided the answers arrive by Tuesday.

These dependencies are real. They belong in the schedule. The agency cannot manufacture an approval or grant itself access to someone else’s infrastructure.

And “waiting on the client” is a useful account of a particular unanswered request. It becomes less useful when it describes the entire project for seven consecutive weeks. It tells everyone where the frustration sits. It does not tell anyone which decision would release the work.

Finished has no owner.

Everyone completed a task. Nobody owns the release.

The designer means the layouts are approved. The developer means the agreed components are implemented. The account director means the client has seen the latest preview. The client means the website can begin receiving customers. All four can be speaking accurately about different states.

The project has a completion percentage but no shared release condition. “Four things left” gives no account of which things block launch, who can accept them, what evidence closes them, or when the resulting decision will be made.

The first repair is a release record that distinguishes those conditions:

• A defect: the mobile heading fails an agreed layout requirement. Name the fix, the person checking it and the evidence that closes it.
• An operational decision: the enquiry form needs an accountable recipient. Name who chooses the destination and who confirms a test submission arrived.
• A requested change: the photograph is being replaced. Ask the authorised client contact whether the current approved image may launch or whether replacement is a genuine release condition.
• An undefined task: “check redirects” needs an agreed inventory of relevant old URLs, their intended destinations and a recorded test result.

Give the combined release a named owner with authority to coordinate the decision. Confirm deployment access, the agreed checks and a recovery procedure. Put additional requests into a separate, visible queue with their own commercial treatment. A launch date can then be tied to explicit dependencies rather than repeated optimism.

This does not make the client’s concerns smaller. It makes them answerable. Where an external approval is essential, the record should say exactly what is blocked and by whom. Where a change can wait, that decision should be agreed rather than quietly assumed.

The team may need a few hours of implementation. It may need a more substantial investigation. The release record lets the agency distinguish those cases before promising another Friday.

The staging link can remain where it is. “Finished” finally has somewhere to go.