---
name: verify-before-ship
description: "Verify a change actually works by exercising the rendered output, not just by trusting a green build. Use before committing or shipping any nontrivial change: check the real HTML or UI for leaked frontmatter, unstyled text, broken layout, and placeholder strings, in both light and dark mode when the change touches styling. A passing typecheck or test suite proves the code compiles, not that the page is correct."
---

# Verify Before Ship

A green build means the code compiles. This is the check that means the page is actually right, run against the real rendered output before anything ships.

## Phases

Work through these in order.

### 1. Build

Run the smallest relevant checks first (typecheck, lint, tests). Treat a pass here as necessary, not sufficient.

Read: [working-with-me](https://selwynuy.dev/d/working-with-me.md)

### 2. Render

Start the dev server and load the actual page or component the change touches. Curl or screenshot the real output, don't infer correctness from the diff.

Read: [working-with-me](https://selwynuy.dev/d/working-with-me.md)

### 3. Inspect

Check for the specific failure class that a build can't catch: raw frontmatter leaking into the page, unstyled or truncated text, broken layout at common breakpoints, placeholder or TODO strings, and (if styling changed) both light and dark mode.

Read: [error-handling-ux](https://selwynuy.dev/d/error-handling-ux.md)

## Bundled files

- `references/rendered-output-checklist.md` (reference): The specific things a green build hides: frontmatter leaks, broken empty states, theme regressions, and how to check for each.

---

Part of Verify Before Ship from Selwyn Uy's Next.js Handbook. Full page: https://selwynuy.dev/skills/verify-before-ship