Feature Development Checklist

PM owns the PRD; tech lead reviews. Each story needs Given/When/Then acceptance criteria specific enough that QA can write test cases without follow-up questions. Attach the doc (Notion, Confluence, or Google Doc) here so the run has a permanent link.

Does the feature collect new PII, change data retention, expose new audit-log surface, or alter access control? Loop in security if any of those are yes — getting Vanta/Drata evidence retrofitted post-launch is painful. Note GDPR data-subject-rights impact if EU users are in scope.

Cover the chosen architecture, the key API contracts, error handling, observability (which metrics, which logs, which traces), and rollback strategy. Name third-party services and the failure mode if they're down. Link to any related ADRs.

Forward-compatible only: new columns nullable, no destructive changes in the same release as code that depends on them. For tables over 1M rows, use ADD COLUMN (no default) + batched backfill + follow-up default — adding a defaulted column on Postgres rewrites the table under exclusive lock.

Create the flag with a named owner and a planned retirement date. Default off in production; on for internal users in staging. Record the flag key in the design doc so the post-launch cleanup step can find it.

Target PRs under 400 lines of diff — reviewers skim larger ones. Each PR should be independently mergeable behind the flag, even if the user-facing feature is incomplete. Avoid the long-lived feature branch anti-pattern; merge to main daily.

Coverage target per the team's standard (commonly 80% line, but enforce on diff coverage rather than total). Integration tests cover the new API contracts end-to-end against a real DB. Mark any new flake-prone tests with retries and an owner — don't ship known flakes.

Cut a release candidate tag (e.g., v2024.45.0-rc.1) and run the full Playwright/Cypress suite in staging. Investigate any new failures; do not whitelist or skip them to unblock the release.

QA lead and tech lead together categorize each bug: blocker (ship-stopper), major (ship with known-issue note), or minor (file follow-up). Capture the count of remaining blockers below — anything over zero halts the release.

Migrations go out ahead of the application code that depends on them, since old code must keep working against the new schema. Watch replication lag during the migration; abort and roll back if lag crosses the team's threshold (commonly 30s).

Route 5% of traffic to the new build for at least 10 minutes. Watch error rate, p99 latency, and saturation against the canary's own dashboard — comparing canary to baseline catches regressions that absolute thresholds miss.

The release captain stays primary on Datadog/Sentry alerts for 24 hours post-deploy. Compare error rate against the trailing 7-day baseline and the SLO error budget burn rate, not just absolute counts.

Release captain makes the call after the 24-hour soak. Criteria: error budget not burning faster than baseline, no SEV2-or-worse open against the feature, no customer-support spike. When in doubt, roll back — the cost of rollback is always less than the cost of a prolonged regression.

Flip the feature flag off first — that's the fastest and least risky rollback. If the regression is in code paths that ran regardless of the flag, redeploy the previous container image. The DB migration is forward-compatible, so it stays in place. Open a SEV2 incident and start the standard incident-response workflow.

Internal changelog goes to #engineering with the deployed sha. Customer-facing release notes (if user-visible) go through the standard PMM review and land in the docs site or in-app changelog.