The Last Hour Before Launch: A 60-Minute Shipping Runbook for Vibe Projects

First, the Boundary: What This Guide Is Not

This is not another launch checklist. A checklist answers "did we forget anything?" and it should be finished the day before launch. This guide answers a different question: in the final hour, what happens each minute, who decides, and when do you stop immediately? If you do not yet have a passed launch checklist, go back and complete that first. The final hour cannot make up for it.

Nor is this about launch-day marketing, cold-start copy, or gradual rollout strategy. Those belong after launch. The final hour has one job: take a version that is already ready, ship it safely and reversibly, and then stand guard over it.

Three Rules for the Final Hour

First, freeze scope. From T-60 onward, only three kinds of change are allowed: fixes for blocking defects, typo corrections, and configuration corrections. Anything else, even a one-line "quick improvement," waits for the first patch window after launch. The most common final-hour accident in vibe projects is not a missing feature. It is someone turning a "quick fix" into an incident.

Second, one decision-maker. Ship, delay, and roll back are decided by one person, who must be online for the whole hour. Group votes, emoji polls, and "what does everyone think?" are invalid in the final hour. If the decision-maker is absent, there is no decision, and the default is delay.

Third, prepare the rollback before you talk about shipping. A rollback is not a backup plan for failure. It is the ticket that admits you to ship at all. If you cannot say how you return to the previous version within three minutes, you are not ready to press the deploy button. The rollback path must have been walked through for real before T-60, not merely written in a document.

The 60-Minute Schedule: Follow It, Do Not Improvise

T-60 to T-45: Freeze confirmation and rollback rehearsal. The decision-maker confirms three things, one by one: the release scope is locked and written on the release sheet; the rollback steps have been rehearsed and the previous build and database snapshot are at hand; the on-call person is in place and knows who to contact first. If any item cannot be answered, enter the delay procedure at once. Do not fill gaps while walking.

T-45 to T-30: Final smoke test in the staging environment. Run only the core flows: open the home page, complete one signup or login, complete one payment or core action, and confirm one critical data write. A smoke test is not full regression. Do not add tests in this window. If the smoke test fails, fix that one point only, then rerun the smoke test without expanding scope.

T-30 to T-15: Final configuration and secrets check. Check production configuration item by item: domain routing, environment variables, production keys for third-party services, payment callback URLs, and the email sending domain. In vibe projects, what breaks most often is not code. It is a test key carried into production, or a callback URL pointing at a local address. Check in pairs: one person reads the item aloud, the other confirms it against the production console.

T-15 to T-5: Finalize the release sheet and the announcement. Write three sentences: what shipped, what users will see change, and where users should report problems. Do not wait until after launch to write the announcement. After launch you will be watching metrics, with no time to write human sentences. Known issues belong in the announcement, stated honestly. A hidden issue returns in the comments at ten times the volume.

T-5 to T-0: Ship. Execute the planned steps without changing them mid-flight. After deploying, do not announce yet. Watch five minutes of metrics first: error rate, core API latency, and login success rate. If the numbers are steady, announce. If they are abnormal, decide against the rollback triggers first. Do not announce and then fight the fire.

Go and No-Go: Five Red Lines, Any One Stops the Launch

Write the five lines below into the release sheet and have the decision-maker check each one. Any failure is a No-Go. No discussion, no "let us wait and see."

• Rollback path not rehearsed: you cannot say how to return to the previous version within three minutes, or the previous build is not at hand.
• Core flow smoke test failed: any of signup, login, core action, or payment fails in staging.
• Production configuration not double-checked: any key, callback URL, or domain routing was seen by only one person.
• On-call person missing: nobody is clearly on call for two hours after launch, or the on-call person does not know where alerts go.
• Scope expanded in the final hour: an unplanned feature was slipped into this release, however small.

Counter-example: at T-20, a team spotted a non-blocking layout misalignment. The developer "quickly" fixed it and refactored the related stylesheet on the way. The stylesheet then failed under the production build, and the home page went blank. The misalignment itself would not have bothered users. A blank page bothers everyone. The correct move was to log the misalignment for the post-launch patch list and ship as planned.

Rollback Triggers: Written in Advance, Not Negotiated Mid-Incident

The hardest part of a rollback is not technical. It is the decision. Under post-launch adrenaline, people instinctively want "five more minutes" or "one more fix." That is why triggers must be written in advance. When the number is reached, execute. No negotiation, no delay.

Here is a trigger template you can copy: within 15 minutes after launch, if the core API error rate exceeds three times the pre-launch baseline, or the login success rate falls below 95%, or any user data write fails, roll back at once. Restore service first, then review the cause. Do not hold a postmortem while the service is still down.

Rehearse the rollback for real. In an off-peak window, redeploy the previous version, confirm the database snapshot restores, confirm user sessions survive, and confirm third-party callbacks do not fire twice. Teams that have only written "we can roll back" almost always discover a broken link the first time they truly roll back.

Another common counter-example: the rollback button exists, but the database schema has already changed, and data written by the new version cannot be read by the old one. The fix belongs in the release strategy itself: schema changes should be additive only, never destructive. Destructive cleanup waits for a later, separate release. The final hour is not the time to solve data compatibility. Compatibility must be guaranteed during development.

The 30 Minutes After Launch: What the On-Call Sheet Looks Like

Shipping is not the finish line. The 30 minutes after shipping are the real exam. The on-call sheet needs at least four items: the monitoring dashboard link, the alert channel, the rollback steps link, and the public announcement link. The on-call person records three numbers every 10 minutes: error rate, core API latency, and new user reports. Thirty steady minutes ends the watch. Steady does not mean unwatched. It means watched throughout.

Route user feedback by type. Feature suggestions go on the list for later scheduling. Errors and "cannot use it" reports go straight into the handling queue. The most common on-call mistake in the final hour is treating all feedback as the same priority, so the real outage drowns in suggestions.

If everything stays steady, do three closing tasks: record the actual ship time, the actual scope, and any anomalies in the release log; move every change deferred during the final hour onto the next patch list; and send the team a short closing message stating the launch succeeded, the watch is over, and when the next window opens. The closing message is not ceremony. It tells everyone this round is closed, and nothing more gets slipped into this version.

A Release Sheet Template You Can Copy

Copy this table into your project docs and fill one out for every release. Any item you cannot fill in is itself a reason for No-Go.

• Scope this time: list the changes, one sentence each. Unplanned changes must not appear.
• Decision-maker: name and contact, online for the whole hour.
• Rollback steps: concrete steps to return to the previous version within three minutes, with the rehearsal time noted.
• Smoke test result: pass records for the four core flows in staging.
• Configuration check: paired cross-check sign-off, covering domain, keys, and callback URLs.
• Rollback triggers: numeric red lines for error rate, login success rate, and data-write failure.
• On-call plan: who is on call for two hours after launch, the alert channel, and the logging rhythm.
• Public announcement: three finalized sentences, including known issues and the feedback entry point.

The method of the final hour compresses into one sentence: make every decision before the final hour, and spend the final hour only executing decisions, never making new ones. When a vibe project can do that, shipping stops being a gamble and becomes a repeatable operation.