The week before launch — how we close projects

A project rarely fails in the last week. It disappoints in the last week — quietly, in the gap between “the work is finished” and “the work is ready to meet people”. Those are not the same state, and only one of them has a date attached.

So we run the same closing sequence on every project, whatever the category. None of it is glamorous. All of it is the difference between handing over files and handing over something that lands — which is most of what clients are actually buying.

Two reviews, held apart

Every project gets a craft review and a business review in the final week, separately and never in the same meeting. The craft review asks whether the work is finished. The business review asks whether the work earns the brief. Those questions sound like siblings and produce different answers often enough that combining them hides the second one.

The last-mile checklist

• Every asset exported at the size and format its destination actually consumes.
• Type checked on the real device, not on the designer's laptop.
• The first three things a user meets on launch day, sanity-checked by someone outside the project.
• A one-page “what to expect” note in the handoff for whoever inherits this.
• A rollback plan nobody believes will be needed.

Teams that close well treat that week as its own deliverable, with scope and a review of its own. Teams that treat it as overhead produce launches that feel like overhead, and everyone can tell which is which by the second day.

And then, a week later

A short retro inside seven days, before memory softens into a nicer version of events. One question every time: what did we ship that we would not ship again? The answer is almost never the loud thing. It is usually a quiet compromise made on a Tuesday three weeks earlier, and naming it out loud is the entire mechanism by which the next project gets better.