ArchCode
Free template · Delivery review

Delivery Review Checklist

The checklist we use before we quote work. Score each area Red / Amber / Green to find the highest-impact fixes for your team.

← All templates

Run through this checklist with your team or on your own. Score each item honestly. Any Red item is a risk to your releases or production stability. Focus on fixing Reds before Ambers.

Red — Not in place, active risk
Amber — Partial, needs improvement
Green — In place and working
# Delivery Review Checklist Team: [team name] Date: [date] Reviewer: [name] --- ## 1. Release flow How does code get from a developer's machine to production? [ ] R / A / G Releases are automated — no manual steps required on production servers [ ] R / A / G A rollback can be performed in under 10 minutes [ ] R / A / G Rollback has been tested — it is not theoretical [ ] R / A / G Any engineer on the team can trigger a release (no single point of failure) [ ] R / A / G Release frequency is weekly or faster ## 2. CI/CD pipeline What happens between a PR merge and a production deploy? [ ] R / A / G Automated tests run on every PR (unit and/or integration) [ ] R / A / G Linting or code quality checks run in CI [ ] R / A / G Dependency vulnerability scanning runs in CI [ ] R / A / G Staging deploy is automated before production [ ] R / A / G Production deploy includes a health check gate ## 3. Environments How consistent are dev, staging, and production? [ ] R / A / G Dev, staging, and prod use the same infrastructure setup [ ] R / A / G Infrastructure changes go through a review process (no manual changes without a PR) [ ] R / A / G A new environment can be created in under 1 hour [ ] R / A / G Secrets are managed via a secrets manager (not in .env files in the repo) [ ] R / A / G Access roles are documented and follow least-privilege ## 4. Observability Can you detect and diagnose a production incident? [ ] R / A / G Structured logs exist and are queryable in a central location [ ] R / A / G A dashboard shows errors, latency, and availability at a glance [ ] R / A / G Alerts are in place for the metrics that matter most [ ] R / A / G Alert noise is low — fewer than 5 false positives per week [ ] R / A / G At least 3 runbooks exist for the most common failure modes ## 5. Security basics in delivery Are common delivery-layer security risks covered? [ ] R / A / G No secrets are committed to git (checked via scanning or policy) [ ] R / A / G CI/CD credentials use short-lived tokens or OIDC (not long-lived API keys) [ ] R / A / G Production access is restricted to the minimum number of people [ ] R / A / G Container images are scanned for vulnerabilities before deploy [ ] R / A / G Access is revoked within 24 hours when someone leaves the team --- ## Summary Red items (active risk): [count] Amber items (needs work): [count] Green items (in place): [count] Top 3 highest-impact fixes: 1. [Highest-impact Red item] 2. [Second-highest-impact item] 3. [Third item] Recommended next step: [Free Delivery Review / internal sprint / specific package]

Want us to run this review for you?

The Free Delivery Review covers all 5 areas above and gives you a ranked "Top 10 Fixes" report within 48 hours — at no cost.

Get a Free Delivery Review