Frontend Architecture Checklist

Use this checklist before a redesign, platform migration, major feature build, or production hardening pass. It helps teams review architecture decisions without turning the review into an abstract debate.

• Every route has a clear owner and primary user job.
• Shared layouts are intentional, not copied across route groups.
• Loading, empty, and error states are defined at route boundaries.
• Deep links remain stable across authentication and onboarding states.

• Server, client, and cached data responsibilities are documented.
• Mutations have optimistic, loading, success, and failure behavior.
• Components do not fetch hidden global data without a clear boundary.
• Error reporting includes enough context for production debugging.

• Feature components own product behavior.
• UI primitives stay presentation-focused and reusable.
• Cross-cutting concerns like analytics, flags, and permissions have shared helpers.
• Component APIs prefer explicit props over broad configuration objects.

• Colors, spacing, typography, and shadows use tokens.
• Layout patterns are consistent across similar surfaces.
• Responsive behavior is tested at real product breakpoints.
• Dark mode and high-contrast states are not afterthoughts.

• Critical flows have monitoring and useful error messages.
• Expensive work is moved off render paths where possible.
• Accessibility checks are part of the review, not a final pass.
• The team can explain what should be easy to change next quarter.

Turn the review into three lists: fix now, document, and revisit later. Architecture work becomes useful when it produces a smaller set of decisions the team can act on.