The post-launch support checklist: defect cover, a question window, and how to agree both in writing

Post-launch support after a fixed-scope build should be two written windows, not a vague promise: one for defects in the delivered work, one for questions about it. A post-launch support checklist makes both real with 6 items: the dates, one channel, a defect rule, a bug report format, a fix and retest loop, and a record of every report.

The post-launch support checklist: what these two controls are, together

Post-launch support after a fixed-scope build is two windows with written terms: a defect window for bugs in the delivered work, and a question window for how the system runs and how to change it safely. Each needs start and end dates, one channel and a record; the defect window also needs a written defect rule.

Support terms are one line in a longer handover, which also moves the code, the access and the documents; that wider picture is what a developer handoff looks like. Both windows count from the handover date, so pin that date down first. A recorded walkthrough gives you an exact one, which is a good reason to learn how to run a technical handover session before the day arrives.

The table below uses my own working terms for what each window covers and leaves out. Neither is a legal definition, and your contract can word them differently, as long as it words them.

A post handover support checklist is the same six items under another name, because both windows count from the handover date, whatever day the app launched. In my reading, the post-launch support period is simply the defect window’s dates as your contract writes them, so read the contract before you assume a length. To agree post-project support, put the six items in the email that confirms sign-off and ask the builder to reply to that email saying yes. The first item is to confirm the support start and end dates, both as calendar dates with a day and a month, never as “two weeks after go-live”, because a relative date leaves each side free to count from a different day.

In the Production Hardening Sprint, these two windows are deliverables 13.5 and 13.7. Deliverable 13.5 provides fourteen calendar days after handover to fix defects in the sprint deliverables, because issues discovered just after delivery need a clear route back to the team. Deliverable 13.7 provides thirty calendar days after handover for questions about the delivered architecture, operation, and safe future changes.

What is go live support, and how it differs from a defect window

Go-live support is hands-on help given to the people using a new system in the first days after it goes live, and it is counted from the launch, not from the handover. In practice that can mean someone who sits close to the users, answers “where did that button go”, watches the error log and smooths out the first logins.

A defect window is a different promise. Go-live support helps people use the system; a defect window fixes what was delivered when it does not behave as agreed, and it ends on a written date. One launch can have both, so write the two sets of dates separately. A post go-live support plan template is just the two-window table above with the dates, the channel and the names filled in. Preparing the launch day itself belongs to the go-live checklist.

What goes wrong without them

A bug found right after project delivery is normal, in my reading. New code meets real users, real data and real browsers for the first time, and something may behave differently. What hurts is having no agreed route for that bug, so the four failures below are about the route, not the bug.

Each first check points at a document that should exist before sign-off, starting with the software project handover checklist.

How to set them up

Write both windows before sign-off, in the same message, so the builder agrees to them together. Then, when you retest a reported defect after a fix, both of you already agree on what counts as fixed.

Defect cover: the terms in writing

Defect cover carries more terms than the question window, because it is where “is this a defect?” has to be settled. Here are the six items, each with the mistake I’d watch for and what to record.

1. 01 Start and end dates, counted from the handover date and written as calendar dates. The mistake: a relative date like "two weeks after launch". Record: both dates in the sign-off email.
2. 02 One channel, written down, with the person who watches it. The mistake: a channel nobody watches, such as a shared inbox no one owns. Record: the channel and the name.
3. 03 The defect rule. My working rule: when the delivered work does something other than what was agreed, that is a defect; a new capability or a change of mind is a change. The mistake: leaving the word undefined, so every report turns into a negotiation. Record: the rule, in one sentence, in the same email.
4. 04 The bug report format, given below. The mistake: a one-line message such as "checkout is broken". Record: the format, attached or pasted into the email.
5. 05 The fix loop: reproduce, fix, deploy, then retest by running the reporter's own steps again on the new build. The mistake: closing a report because the code changed, not because the steps now pass. Record: the build or commit the retest ran on.
6. 06 The record itself: one row per report with the date reported, the date fixed and the retest result. The mistake: keeping the history in a chat thread. Record: a spreadsheet or an issue tracker both of you can read.

The fourth item is how to report a bug after handover, and it decides whether the builder can start work without a call first. A report in this format gives the builder what they need to reproduce the problem:

1. Steps to reproduce, numbered, starting from a signed-out browser or a named test account.
2. What you expected to happen.
3. What happened instead, with the exact error text if one appeared.
4. The environment: browser and version, device, and which account or role you used.
5. A screenshot, a screen recording, or the log line with its timestamp.

If the code lives on GitHub, GitHub’s issue templates can turn that format into a form. Issue forms are templates with web form fields; a repository can pick different input types and set inputs as required, and the inputs become a standard markdown issue comment when the issue is opened. The five fields above are my choice, not GitHub’s; marked as required in a form, they are harder to skip.

The fifth item is the whole loop for fixing software bugs inside the window. The builder reproduces the report first, because a fix for a bug nobody reproduced is a guess. Then they fix it, deploy it, and you run your own reproduction steps again on the new build. Running the reporter’s own steps is my working method, and it matters because the person who reported the bug is the one who knows what “fixed” should look like. Bug resolution is the close: the row gets the fix date, the retest result and a one-line note of what changed, such as the file or setting that was wrong.

The question window: what is in and out

The question window is quieter, but it fails in the same ways when nobody writes it down. Four items cover it.

1. 01 The channel, plus the access instructions: where to post a question, who answers, and what you need to get in (an invite, a workspace, a repository role).
2. 02 The start and end dates, as calendar dates, counted from the same handover date as the defect window.
3. 03 What a question is: how a part of the system works, how it runs, or how to change it safely. What it is not: building the change. My working rule is that once the answer turns into code someone has to write, it is new work.
4. 04 The answer record: the question, the answer and the date, kept where the next person will look, such as a docs folder in the repository rather than a chat history that expires.

Kept up for the whole window, that answer record becomes the start of the app’s documentation, the same material covered in how to write technical documentation for a vibe-coded app.

How to verify each one

A defect window is verified by its record, not by the contract: the dates, the channel, and for every report the reproduction, the fix and the retest result. A question window is verified by the channel, the access instructions and the dates. One test bug and one test question, sent in the first week, show that both channels work.

Each check below can fail, and each leaves evidence you can point to later.

1. 01 Send one harmless test bug through the agreed channel, in the report format. Evidence: how long the reply took, and the record row it created.
2. 02 Send one test question through the question channel. Evidence: the answer, and its entry in the answer record.
3. 03 Read the record for a real report: every row has reproduction details, a fix and a retest result. Evidence: no row is closed without a retest result.
4. 04 Check that both end dates are written as calendar dates in one place you can find without asking. Evidence: the dates and where they live.

Sending the test bug within about the first week of the window is my working rule, not a contract term; any later and a broken channel eats too much of a short window before anyone notices. The test report can be about something small and real, such as a typo on one page, written up in the format. If the reply comes back asking for the details the format already gave, the format was not read, and that is worth fixing while the window is still open.

In the sprint, deliverable 13.5 is verified this way: record the coverage dates, reporting channel, reproduction details, fixes, and retest results. Deliverable 13.7 is verified this way: provide the channel, access instructions, and the start and end dates in the handover.

After the windows close: web maintenance and support, and what an SLA would mean

Web maintenance and support is ongoing work bought after handover to keep an app updated and running. A defect window is not that: it fixes what was delivered and ends on a written date. An SLA is a third thing: a service contract defining the level of service, such as the time to recover from an operational failure.

The arrangements that come after the windows belong to other articles, so here they get one pointer each. Who looks after the app once nobody is contracted to, and the arrangements that keep it alive, is the question of who maintains an app built with AI. What a web application support and maintenance package contains is the subject of app maintenance services. Buying engineering hours by the month is a web developer retainer. Comparing application maintenance service providers is a separate job again.

An SLA is easy to mix up with a defect window, because both have dates and both can mention fixes. NIST’s definition of a service level agreement gives several versions; the CNSSI 4009-2022 one says an SLA “Defines the specific responsibilities of the service provider and sets the customer expectations.” The SP 800-47 Revision 1 version lists aspects such as “responsibilities, details on the type of service, expected performance level (e.g., reliability, acceptable quality, and response times), and requirements for reporting, resolution, and termination.” In my reading, an SLA in cyber security is the same kind of contract written for security services, where the level of service covers things like recovering from a system compromise, the example NIST SP 800-152 gives. Before you sign one, check that it names each of those parts: the responsibilities, the expected performance level and response times, and the terms for reporting, resolution and termination.

My working rule for the boundary: if you want cover after the defect window’s end date, buy it as one of those arrangements and write it down on its own, because a defect window does not stretch into a maintenance plan or an SLA just because the app is still running.

Where the sprint does this

The two windows run after handover, as deliverables 13.5 and 13.7 described above. At handover, the client receives the updated codebase, tests, and deployment configuration; a readiness report and technical due diligence pack; instructions for releases, backups, recovery, and incident response; guidance and automated checks for future AI-assisted changes; and a recorded 60-minute handover and a 20-30-minute codebase tour. The production readiness report, deliverable 13.1, accounts for all 123 IDs, keeps failures visible until resolved and explains genuine non-applicable items. New features that change the product’s core capabilities are separate work. Every deliverable, with how we verify it, is in the published scope of the sprint.

Common questions about support after handover

What should you do if you identify a defect?

Check two things before anything else: whether today’s date is inside the defect window, and whether the behavior differs from what was agreed under the written defect rule. If both are true, send it through the agreed channel in the report format from the defect cover section, and leave the code alone until the builder has reproduced it.

What are the four steps of defect management?

My working four are report, reproduce, fix, and confirm by retest. They are my own list for a small handover, not a standard’s list. The fourth is the one the record proves, which is why every row needs a retest result before it closes.

What does “retest” mean?

Retest means running the steps that failed again, on the fixed build, to confirm the fix works. In my usage it means the reporter’s own steps, run on the new build, with the result written into that report’s row.

How to write a support plan?

Write it on one page: the six defect-cover items, the four question-window items, and a line on what happens after both windows close, whether that is a retainer, a maintenance contract or nothing. Send it with the sign-off email and keep the builder’s reply.