Angular architecture review: a clear picture and a prioritised plan

I read the code, run the tests and talk to the people who work in it. The review then covers six areas:

• Boundaries. What is product and what is reusable; whether the libraries, Nx projects or folders enforce that line or only suggest it.
• State and data flow. Who owns a selection, a form draft or a server record, how changes propagate, where signals, services and the router meet.
• Shared UI. Which patterns are built several times, which behaviours have one owner (keyboard, focus, grid state, form state) and which have three.
• Testing strategy. What the unit tests prove, where end-to-end tests are missing or slow, how well the checks protect important user journeys.
• Build and delivery. Upgrade path, lint rules, CI time, how a change reaches users and how it could be reverted.
• Accessibility and devices. Keyboard paths, touch targets, phone layouts, where a rule belongs to the library rather than to each screen.

• A written report: findings ordered by impact, each with evidence from the code and the recommended next step and relevant trade-offs.
• A prioritised backlog: units of work with their files, checks and done criteria, so they can be delivered one at a time, by your team or by me.
• A decisions register: the architectural decisions that should stay written down, with their reasons, in the form I use on my own product.
• Pairing sessions where the findings need a conversation rather than a document.

A focused review can be scoped around one week. A broader review depends on the application size, access and people involved; I estimate it after we agree on the questions and outputs. The plan is yours to keep, whether or not we continue together.

• A team whose Angular application is slowing down: every feature touches more files than it should.
• A product preparing a major upgrade, a move to standalone components, signals or a zoneless setup.
• A company with several Angular applications that solve the same interface problems differently.
• A technical lead who wants a second perspective before an expensive decision.

GeoAtlas, my own product, shows one approach: a domain application over shared UI and a map library, with recorded decisions and CI checks. It is evidence of my engineering practice, not a template every application should adopt. Your review starts with your product and team constraints.