A design-system audit for the product you actually have.

What the audit is for

An audit is a close reading of the places where the product loses time: design decisions that get lost on the way to code, components with unclear jobs, exceptions that become the default, and flows that need a restart to grow.

The output is a priority map. It names the work worth systematising now, the work that can wait, and the smallest credible route between them.

• A product and interface inventory
• A practical token and component review
• A map of repeated patterns and expensive exceptions
• A focused recommendation: foundations, patterns, or implementation first

Good systems begin with a boundary

The useful boundary sits where a decision repeats often enough, or costs enough attention, that the team should be able to reach for a settled answer. Everything else stays a one-off, and that is fine.

What you leave with

A concise working document, a set of annotated priorities, and a recommendation for the next six to twelve weeks. Clear enough to act on; specific enough to challenge.