Code review before production is not a ceremony for approving a diff.

It is a deliberate attempt to find the gap between what the code appears to do and what the system will do with real users, real data, failed providers, repeated requests, and imperfect operations.

I do not apply every question below with the same weight. A static marketing page and a payment callback have different risk. The checklist helps me adjust the depth without forgetting important categories.

Start with the intended behavior

Before reading implementation details, I want to know:

• What user or system outcome changes?
• Which route, job, component, or data model owns that behavior?
• What is explicitly outside the change?
• What evidence shows acceptance?
• What existing behavior must remain compatible?

Without that context, a reviewer can approve locally tidy code that solves the wrong problem.

A compact scope is useful here. My process is described in requirements to shippable scope.

Trace the complete path

For a user-facing change, I trace from entry to effect:

1. user action or external event;
2. client-side state and validation;
3. server boundary;
4. authentication and authorization;
5. domain rule;
6. persistence or provider call;
7. response and user feedback;
8. logging, metrics, or audit evidence.

This reveals gaps that file-by-file review can hide.

A disabled button, for example, is not authorization. The server action or API route must still enforce access.

Review every trust boundary

Anything entering from a browser, webhook, file, environment variable, database record, URL, header, or external API deserves validation appropriate to the risk.

I check:

• syntax and size limits;
• domain meaning, not only type shape;
• ownership and tenant scope;
• allowlisted fields;
• safe query construction;
• output encoding;
• upload type and storage rules;
• redirect and URL restrictions;
• webhook signature and replay protection;
• secret handling and log redaction.

TypeScript helps developers reason about code. It does not validate an untrusted request at runtime.

For systems with tenant data, this review connects directly to secure multi-tenant SaaS foundations.

Look beyond the happy path

Happy-path code is normally the easiest part to read.

I ask what happens when:

• a provider times out;
• the same action is submitted twice;
• the user navigates away;
• one operation succeeds and the next fails;
• a database write conflicts;
• a queue retries;
• a record no longer exists;
• the response arrives out of order;
• a dependency is degraded;
• cleanup itself fails.

The answer may involve idempotency, transactions, compensation, bounded retries, cancellation, or a clear recoverable state. It depends on the operation.

The important part is that failure behavior is designed, not accidental.

Check the user-visible states

A production review should include more than the successful screenshot.

For interactive UI, I check whether the implementation accounts for:

• loading and pending;
• empty data;
• validation errors;
• server errors;
• disabled actions;
• success confirmation;
• long text and narrow screens;
• keyboard operation;
• visible focus;
• accessible names;
• reduced motion;
• repeated submission;
• stale data.

The interface should tell the truth about system state. A button that looks finished while work is still pending creates both usability and data risks.

Check data compatibility

Data changes deserve special care.

I look for:

• old records missing new fields;
• new enum values reaching older code;
• default behavior during rolling deployment;
• index or constraint changes;
• backfill requirements;
• migration restart safety;
• rollback consequences;
• serialization changes;
• timezone and date assumptions.

“The model compiles” is not evidence that stored production data is compatible.

Review API contracts as contracts

An API change affects every caller, including callers not visible in the edited folder.

I check:

• request and response schemas;
• status codes;
• error shape;
• authentication requirements;
• pagination and ordering;
• idempotency behavior;
• version or compatibility strategy;
• timeout and cancellation behavior;
• documentation and examples.

The deeper design principles are in API contracts that survive growth.

Check performance where the change spends resources

I do not label every loop a performance problem.

I look at likely production costs:

• repeated database queries;
• unbounded result sets;
• sequential independent I/O;
• large client bundles;
• expensive server rendering;
• duplicate provider calls;
• missing caching or invalidation;
• image and font payload;
• work inside hot request paths.

The review should connect cost to a user path and measurement plan. For frontend limits, see the performance budget I use for client projects.

Ask how the change will be operated

Before production, someone should know:

• which configuration is required;
• how secrets are supplied;
• what signals indicate success or failure;
• which alerts need an owner;
• how support can identify the affected request;
• whether a feature flag exists;
• how to roll back;
• whether documentation changed.

Observability is not permission to log everything. Logs should be useful while excluding secrets and unnecessary personal data.

Match tests to the risk

I prefer focused tests that prove behavior at the right boundary.

Examples:

• pure unit tests for domain decisions;
• integration tests for storage and authorization;
• contract tests for provider adapters;
• regression tests for a fixed bug;
• end-to-end coverage for a critical user path;
• negative tests for unauthorized or malformed requests.

External APIs, clocks, randomness, and paid services should be controlled in deterministic test environments.

The final review question

My last question is simple:

If this fails in production, will the team know what happened, limit the damage, communicate clearly, and recover?

If the answer is unclear, the code may be finished but the release is not ready.

If you have a release approaching and want an independent production-readiness review, send me the affected path, risk level, and release constraints.