What to Include in a Go-Live Decision Meeting

A go-live decision meeting should determine whether the business can responsibly begin the proposed level of use. It should not be a ceremony for confirming a date already treated as irreversible. Participants need a shared view of unresolved issues, operating responsibilities, and the evidence supporting launch, delay, or a narrower introduction.

Bring evidence rather than general reassurance

Review the important journeys and their observed results. A hypothetical customer booking service should demonstrate that a request reaches staff, the customer understands its status, and changes are handled consistently. Include significant exceptions and identify any checks not yet completed.

The GOV.UK live-phase guidance discusses support, security, performance measures, and continuing quality checks before live operation. A commercial business should assess equivalent concerns appropriate to its service, without assuming that it must copy every government procedure.

Ask the delivery team to distinguish confirmed behavior from assumptions. If the service has been tested only with a limited volume or one device type, state that limitation. A decision is stronger when participants understand the boundary of the evidence rather than hearing only that testing passed.

Review unresolved issues by business consequence

For each significant issue, describe who is affected, what could happen, and whether a practical workaround exists. An inaccurate charge and an inconvenient report layout should not receive the same treatment simply because both appear on the open-issues list.

Identify the owner and proposed action. State whether resolution is required before launch, whether the business can operate within a controlled limitation, or whether the issue is an improvement for later. The distinction should reflect customer and operating consequences, not the inconvenience of moving the date.

Challenge vague workarounds. A statement that staff will manage manually needs an actual process, available people, and a method for reconciling records. If those conditions are missing, the workaround is another assumption rather than a readiness measure.

Confirm operating ownership and availability

Name the business owner, support contact, technical escalation route, and people authorized to approve changes. Confirm that the relevant people will be available during the launch period. Responsibilities recorded in a document are insufficient if the assigned person cannot act when needed.

Review support guidance, training, information maintenance, and any overlap with the previous process. Clarify which record controls live work. Staff should know how to handle a booking created before the change and one created afterward.

Establish the actual provider arrangements, including availability and response expectations. Do not infer service commitments from a general development relationship. Match customer communication to the support the business and provider have agreed to deliver.

Agree the response if launch does not go as expected

Define the conditions that would prompt reduced access, a pause, or a return to an agreed fallback. Discuss who makes that decision and how customers and employees are informed. The objective is to prepare a controlled response rather than improvise under pressure.

Review recovery arrangements for essential records and the checks appropriate to the service. Ask what evidence exists that the process can be followed. The business consequence of losing bookings or payment records should guide the attention given to these questions.

Identify the first review after launch and the measures it will examine. Customer task completion, unresolved enquiries, inaccurate records, and staff workload can provide useful evidence. Avoid relying on traffic or registrations alone when the commercial objective involves completed transactions.

Make Holism's role and the owner's decision explicit

Holism's human developer can explain technical readiness and limitations, directing AI-assisted work and using its Software Product Line foundation where suitable. AI supports implementation and iteration; reusable capabilities offer consistent starting points; the developer applies judgment to difficult cases.

The business owner supplies priorities and decides whether the proposed operating commitment fits the company. The developer should not be left to infer commercial risk acceptance, and the owner should not be expected to make engineering judgments without professional explanation.

Record the decision, scope of launch, unresolved conditions, owners, and next review. A useful meeting ends with an actionable operating choice supported by evidence, including the option to delay or limit access when important readiness questions remain unanswered.