A checklist will never replace judgment.
But after many years of design reviews, I have learned that most serious problems come from a small number of questions that nobody asked. A good checklist makes sure those questions get asked every time, by everyone, even on a busy Friday afternoon.
This is the checklist I use, in condensed form. Use it as a conversation guide, not as a form to fill in.
Business Fit
- What business outcome does this solution deliver, and how will we measure it?
- Is the scope clear, including what is out of scope?
- Does it align with our technology strategy and principles?
- Does a capability already exist that we could reuse or extend?
- Who is the business owner after go-live?
Design
- Is this the simplest design that meets the need?
- Which patterns are used, and why are they appropriate?
- Are responsibilities between components clear?
- Are key decisions recorded, with alternatives considered?
- What are the biggest risks and assumptions?
Data and Integration
- Which system is the source of truth for each key entity?
- Is the integration style right: real time, near real time or batch?
- What happens when a connected system is slow or unavailable?
- Are retries idempotent, so duplicates cannot cause harm?
- How is data quality checked and maintained?
- Is personal or sensitive data moved only where necessary?
Security
- How do users and systems authenticate?
- Do all identities, including integrations and AI agents, follow least privilege?
- Is data encrypted in transit and at rest?
- Which regulations apply, and how are they addressed?
- How is access reviewed over time?
Non-Functional Requirements
- Are performance, availability, scalability and recovery targets defined and measurable?
- How will they be tested before go-live?
Operations
- How will we know if something goes wrong? Are logs, metrics and alerts in place?
- How do we recover from failure, and has it been tested?
- Who supports the solution, and do they have runbooks?
- How will it be deployed and released safely?
Cost and Change
- Do we understand build and run costs, including consumption-based services?
- How easy will it be to change or extend in the future?
- Are we locked into a vendor, and do we have an exit strategy?
- What technical debt are we knowingly accepting?
For AI Solutions, Add
- What data can the AI access, and is that appropriate?
- What actions can it take without human approval?
- How is output quality evaluated and monitored?
- Are prompts, outputs and tool calls logged?
Final Thought
The purpose of a review checklist is not to catch teams out.
It is to make sure the important questions are asked early, while the answers are still cheap to change.