Delivery checklists

Engineering Studio

The first two lists gate a release: Release Readiness before code leaves the branch, and Rollout Plan before the change reaches users. The rest cover the work before that: reading the ticket, planning the module, and asking the questions that surface hidden risk.

Release Readiness

A checklist for deciding whether a change is ready to leave the branch. Use before merging, tagging, or preparing a production deployment.

Quality gate

Confirm the change is correct, tested, and reviewable.

  1. Confirm PR scope matches the ticket and does not hide unrelated cleanup.
  2. Run typecheck, tests, lint, and the relevant build command.
  3. Manually check the critical route or workflow.
  4. Attach screenshots for UI changes or explain why not.

Risk gate

Make the release reversible and observable.

  1. Confirm migrations and data changes are backward-compatible.
  2. Use a feature flag or staged path when blast radius is high.
  3. Confirm PostHog events still fire and new events are named consistently.
  4. Write rollback steps and who owns the decision.

Handoff

Leave enough context for reviewers and operators.

  1. PR summary names changed behavior and affected routes.
  2. Verification list includes exact commands and manual checks.
  3. SEO, locale, analytics, content, and deployment impact are called out.
  4. Monitoring window and success signal are clear.

Rollout Plan

A checklist for moving from merged code to production adoption with guardrails. Use for staged releases, feature flags, customer cohorts, migrations, or high-impact UI changes.

Before rollout

Prepare the environment, audience, and fallback path.

  1. Define target cohort: internal, beta, percentage, tenant, or geography.
  2. Confirm flag/config default and kill switch owner.
  3. Capture baseline metrics, conversion, error rate, and support signal.
  4. Prepare release note, support note, and owner escalation path.

During rollout

Move in small steps and watch leading indicators.

  1. Roll out by phase.
    1. Internal or dogfood users.
    2. Small beta cohort.
    3. 10%, 25%, 50%, then 100% if healthy.
    4. Named tenants only when support is ready.
  2. Watch errors, latency, conversion, PostHog events, and support tickets.
  3. Pause rollout if any rollback trigger is reached.
  4. Log each phase change with timestamp, owner, and reason.

After rollout

Close the loop instead of only shipping the code.

  1. Compare post-rollout metrics with baseline.
  2. Remove stale flags, temporary code, and support workarounds.
  3. Write down what surprised the team.
  4. Create follow-up tickets for debt, docs, and analytics gaps.

From Ticket to First Commit

A practical checklist for clarifying scope, gathering the right context, choosing a plan, and making the first reviewable change. Use before coding when a task arrives from product, support, design, or another engineer.

Understand the task

Clarify the underlying problem before deciding what to change.

  1. Read the ticket and restate the goal in one sentence.
  2. Identify the affected user, route, workflow, or system boundary.
  3. Extract explicit acceptance criteria and mark missing criteria.
  4. Check product, SEO, analytics, locale, accessibility, and privacy impact.

Prepare the work

Reduce uncertainty before opening files broadly.

  1. Find existing patterns, tests, helpers, and nearby ownership boundaries.
  2. Separate must-have changes from nice-to-have cleanup.
  3. Decide what commands, screenshots, or manual checks will prove the work.
  4. Write down the highest-risk assumption before implementation.

Start implementation

Make the first change easy to review.

  1. Start with the smallest behavior-preserving edit.
  2. Add or update tests at the same boundary as the behavior change.
  3. Update PostHog tracking when adding navigation, CTA, filters, forms, preferences, or new routes.
  4. Checkpoint with status if scope or risk changed.

Engineering Delivery Checklist

An eight-phase checklist from task intake to post-rollout review. Use whenever a task may affect architecture, data, traffic, users, production behavior, or team handoff.

Phase 1: Intake

Understand the real problem before choosing a technical shape.

  1. Name the business or user problem and the success metric.
  2. Clarify scope, out-of-scope, deadline, priority, and affected users.
  3. Check dependencies, security, privacy, legal, data migration, backward compatibility, and production traffic impact.
  4. Ask AI for clarification questions grouped by business, product, data, API, security, reliability, rollout, and observability.

Phase 2: Discovery

Map the current system before changing it.

  1. Identify services, routes, jobs, APIs, events, data stores, owners, and existing patterns.
  2. Check related incidents, bottlenecks, dashboards, logs, and legacy constraints.
  3. Ask AI for a dependency map, impacted components, integration points, risks, and missing information.

Phase 3: Design

Compare options and choose the simplest design that handles the real risk.

  1. Create an ADR when the decision affects architecture, data, dependency, or rollout.
  2. Compare at least three options by complexity, scalability, consistency, cost, migration, rollback, and maintainability.
  3. Decide sync API or async event, CRUD or CQRS or Event Sourcing, indexes, transaction boundary, cache, idempotency, retries, Circuit Breaker, and security model.

Phase 4: Implementation plan

Turn the design into reviewable PRs.

  1. Break work into backend, database, API contract, tests, observability, rollout, and documentation tasks.
  2. Plan migration, feature flag, backward-compatible API changes, monitoring, rollback, and owner review.
  3. Define unit, integration, contract, E2E, load, security, migration, and rollback checks.

Phase 5: Coding and review

Keep implementation aligned with boundaries and production behavior.

  1. Check architecture boundary, transaction boundary, validation, error handling, and ownership.
  2. Verify retry cannot create duplicate side effects and sensitive data is not logged.
  3. Ask AI to review as a principal engineer for correctness, races, consistency, security, observability, performance, maintainability, and rollback risk.

Phase 6: Verification before rollout

Prove the feature can survive normal and failure paths.

  1. Run unit, integration, contract, E2E, load, security, migration dry-run, and backward compatibility checks as needed.
  2. Prepare dashboard, alert, runbook, rollback path, and customer impact checks.
  3. Ask AI for a production readiness checklist with failure scenarios, monitoring, abort criteria, rollback, and data validation.

Phase 7: Rollout

Release in small steps and watch user impact.

  1. Deploy dark when possible, then enable internal users before canary.
  2. Monitor success metric, error rate, latency, DB load, query plan, queue lag, cache hit/miss, and support signal.
  3. Define success criteria, abort criteria, rollback owner, communication plan, and kill switch.

Phase 8: Post-rollout

Turn delivery into learning and reusable system memory.

  1. Compare expected metrics with actual outcome, regressions, incidents, near misses, and alert noise.
  2. Update docs, ADR, runbook, Studio checklist, and follow-up tickets.
  3. Ask AI for a post-rollout review with outcome, metrics, issues, user impact, technical debt, actions, and lessons learned.

Create a New Module

A checklist for adding a route, feature module, service module, or reusable component without blurring ownership. Use when adding a new feature surface or reusable module.

Define the boundary

A module should have one reason to change.

  1. Name what the module owns and what it depends on.
  2. Define inputs, outputs, and invalid states.
  3. Place files beside existing patterns rather than inventing a new folder style.
  4. Expose a small public API and keep internals private.

Frontend checks

Keep the UI stable, accessible, and measurable.

  1. Cover UI states.
    1. Loading or pending state.
    2. Empty state.
    3. Error or permission state.
    4. Mobile and narrow viewport behavior.
  2. Use existing tokens, icons, spacing, and card rules.
  3. Add page, CTA, filter, search, preference, or outbound events when applicable.
  4. Check labels, focus order, keyboard path, and contrast.

Backend checks

Make contracts explicit before implementation details spread.

  1. Document API/job contract and validation rules.
  2. Check authorization, ownership, and audit needs.
  3. Plan schema, indexes, migration, backfill, and retention.
  4. Add logs, metrics, alerts, and business events if user behavior changes.

Verification

A module is not done until it can be safely changed later.

  1. Add focused unit or contract tests.
  2. Add integration or route tests for cross-boundary behavior.
  3. Run manual checks for the main workflow and one failure path.
  4. Update docs, PR notes, and screenshots when the surface is user-facing.

Senior Engineering Questions

A compact set of questions covering business, product, domain, API, data, consistency, resilience, security, observability, and rollout. Use before implementation when a task looks simple but may hide production, data, or user risk.

Business, product, and domain

Connect implementation to the real outcome.

  1. Which business metric, user group, and deadline matter here?
  2. What are the happy path, edge cases, undo behavior, pending state, failed state, and audit needs?
  3. What are the main entities, aggregate boundary, state transitions, invariants, and domain events?

API, data, and consistency

Make contracts and state changes explicit.

  1. Is the API sync or async, idempotent, versioned, paginated, and backward compatible?
  2. What schema, migration, index, query scale, retention, and PII concerns exist?
  3. Is strong consistency required, can eventual consistency work, and are race conditions or duplicate events possible?

Resilience and security

Assume dependencies and users can behave unexpectedly.

  1. Which dependency can fail, slow down, or return partial failure?
  2. Are timeout, retry, Circuit Breaker, fallback, rate limit, and idempotency designed?
  3. Who can use it, how is authorization enforced, what input is validated, and what should never be logged?

Observability and rollout

Decide how the system proves it is healthy.

  1. What business metric, technical metric, trace, log, correlation ID, dashboard, and alert prove the feature is working?
  2. Is there a feature flag, canary plan, abort criteria, rollback path, migration rollback, and monitoring owner?
  3. What should be archived after rollout so the next task starts with better judgment?

AI-Assisted Feature Workflow

A full feature workflow from idea to spec, implementation, review, rollout, and knowledge archive. Use for meaningful product or engineering changes where multiple AI tools can help without losing ownership.

Shape the work

Use AI to clarify the problem before assigning implementation.

  1. Ask GPT for problem statement, user stories, acceptance criteria, non-goals, risks, rollout, and test plan.
  2. Ask Claude to challenge architecture, assumptions, failure modes, and minimum viable scope.
  3. Split into small Codex or Antigravity tasks that can be reviewed independently.

Execute

Use the right agent for the right kind of work.

  1. Use Codex for repo tasks with tests, clean diffs, refactors, migrations, and PR-ready work.
  2. Use Antigravity for UI-heavy prototypes, browser verification, screenshots, and end-to-end artifacts.
  3. Checkpoint after each small task before expanding scope.

Review and release

Separate execution from review and release judgment.

  1. Use Claude or GPT to review the diff for correctness, security, edge cases, test gaps, and migration risk.
  2. Human owner reviews trade-offs and final merge decision.
  3. Use GPT for release note, stakeholder update, and rollout checklist.
  4. Archive PRD, RFC, decisions, test evidence, and postmortem notes in NotebookLM.