The Handoff Checklist Between Design, Build and Launch

Reviewed by Product Specialist at thinQit. Updated 11 September 2026.

A design review signs off a pricing page: three plan tiers, a monthly-annual toggle, and a comparison table. Four days later the build comes back with three tiers, a comparison table, no toggle, and prices in dollars on a site that sells in euros. Nobody decided to drop the toggle. It lived in a second frame that was never exported, and the currency was chosen by the builder because the instruction did not name one. Both gaps were created at a boundary, not during the work, and both were invisible until someone opened the preview.

This is what a handoff failure looks like in practice. It is not a missed deadline or a disagreement about quality. It is information that existed on one side of a boundary and did not arrive on the other, and it is the most common reason an AI-assisted build returns something plausible instead of something correct.

A delivery cycle has two boundaries, and they fail differently

A product slice crosses two boundaries before it reaches a user: design to build, and build to launch. The first boundary carries intent, what the thing must do, for whom, in which states. The second carries proof, evidence that what was built does what was agreed, plus everything the page needs to function as a live URL rather than as a screen. The two are not interchangeable, and a checklist that covers one does not protect the other.

The failures are distinct. A gap at the first boundary produces work that is finished and wrong: a builder fills the silence with a reasonable guess, and the guess ships. A gap at the second boundary produces work that is right and unverified: the surface behaves correctly in the preview, and nobody has confirmed it behaves correctly under a real route, a real redirect, or a real permission check.

AI-assisted delivery sharpens the first failure in particular. An underspecified instruction and a fully specified one return work of identical visual quality, so the usual signal, output that looks unfinished where thinking was unfinished, is no longer available. The check has to be a list, agreed in advance, rather than an impression formed at review.

Boundary one: what must cross from design to build

Seven items make a design handoff buildable without a follow-up conversation. Each one is missing in a recognisable way, and the recognisable failure is the reason to insist on it rather than assume it.

The exclusion list is the item teams skip most often and the one that changes review the most. A slice with a written exclusion list can be accepted or rejected against a boundary that existed before deadline pressure did. A slice without one is assessed against whatever each reviewer assumed was in scope.

State coverage deserves its own line

Of the seven, state coverage is the item that most reliably separates a preview that demos well from a build that survives contact with users. A reachable surface has at least four states beyond its happy path: nothing yet, still loading, something went wrong, and you are not allowed. Naming those four per surface at the design boundary costs a line each. Discovering them after launch costs a support ticket each.

Boundary two: what must cross from build to launch

The second boundary carries proof and plumbing. A build can be entirely correct and still arrive at launch missing the things that make it a working page rather than a working screen.

• Evidence per acceptance condition. Not a preview link. A record of the condition being exercised: the primary path completed, the declined state rendered, the permission boundary refusing the request.
• Route and redirect map. Every new URL, every URL it replaces, and the redirect between them. Renaming a page without this is how a ranking page becomes a 404.
• Metadata per new route. Title, description, and a self-referencing canonical. Framework defaults inherit from a parent route, which is how a page ends up declaring itself a duplicate of a page it has nothing to do with.
• Structured data. The schema types the page's content actually supports, with identifiers that match the rest of the site rather than a second copy of the organisation entity.
• Analytics events. The event names the new surface emits, agreed before launch, so the first week of data is comparable to the second.
• Rollback path. How this change is reversed, by whom, without a redeploy of everything else.
• Deferred items with an owner and a trigger. The exclusion list from boundary one, carried forward with the condition that would reinstate each entry.

Anything touching credentials or permission boundaries raises the bar on the evidence line specifically, for the reasons set out in the guide to security guardrails for AI agents shipping production code. A preview demonstrates appearance. It does not demonstrate that a role boundary holds.

The checklist is a record, not a ritual

A handoff checklist works only if its answers persist past the slice they were written for. Stored in a chat thread, the answers survive about as long as the conversation stays scrolled into view. The next slice is planned by a different person, or by an AI teammate reading project context, and neither of them has the thread.

This is the job shared project knowledge in Compass exists to do. Decisions, constraints, data contracts, exclusion lists and launch evidence live in one place that both human reviewers and agents read from. The practical test is simple: if the person who wrote the answer left tomorrow, would the next slice still be planned correctly? A record passes that test. A thread does not. The longer version of that argument is in turning project decisions into reusable AI context.

What a handoff item looks like when it is written properly

The difference between a checklist that works and one that is performed is visible at the level of a single line. Compare two versions of the same interaction rule.

Weak: "Add the annual toggle." This names a control and nothing else. A builder receiving it has to decide what the toggle switches, whether the switch is per-plan or global, what the discount is, whether the displayed price updates immediately or on submit, and what the default position is. Five decisions, made by whoever is fastest, none recorded.

Strong: "Monthly/annual toggle above the plan grid, global across all three tiers, default monthly. Annual applies a 20% discount to the displayed per-month price and shows the annual total underneath. Prices render in EUR. The toggle does not appear on the Enterprise card, which shows 'Contact us' in both positions."

The second version is longer because it contains the five decisions, made once, in writing, by the person qualified to make them. A task specified that way can be handed to the Codex Studio build canvas and returned as work a reviewer accepts or rejects in minutes, rather than as a draft that starts a second round of specification.

The handoff after launch is the one with no owner

There is a third handoff that most checklists omit because it has no receiving party. After a release, a set of recurring items needs attention on every new page: internal links from related content, metadata accuracy, canonical correctness, structured data, alt text, and whether the copy still matches what the product does. These are the first items abandoned under deadline pressure, on the reasoning that they can be fixed later, and they are also the items that determine whether the page is legible to search and answer engines during the weeks immediately after release.

This category does not need a human decision every time, which is the argument for handing it to a standing owner rather than a person with a calendar. thinQit's specialist AI teammates hold it as a queue: Sophia audits shipped pages, applies technical SEO and GEO corrections, and reads the change back off the live page rather than reporting an intention. The canonical example above is not hypothetical, an inherited canonical on a legal page is exactly the class of defect that surfaces in a routine post-launch sweep and never in a design review.

Running the checklist in under ten minutes

The list is long to write down and short to run, because most items are answered by pointing at where the answer lives. Three questions cover the boundaries at review time.

1. 1Is every surface reachable from the shipped navigation covered by a condition with evidence attached? A reachable surface with no evidence is unverified work, regardless of how it looks.
2. 2Is every excluded item written down with a reason, an owner and a trigger? An exclusion that exists only in someone's memory is indistinguishable from an omission.
3. 3Did anything move from the first list to neither list during the week? Work is rarely dropped by decision. It is dropped by silence, when an item stops being discussed and leaves the plan without entering the deferred record.

The third question is the one that catches the failure worth catching. It is also the question that only works if the first two were answered in writing at the start of the slice, which is the entire reason the boundaries get a checklist rather than a conversation. The same discipline applied to approvals is covered in how approval gates make AI delivery safer.