Why would you audit? Shouldn't you have already done this at the start? Let's look at a few reasons why a half-way audit might be useful.
Starting in the Middle
Working as a solo developer and designer and developer, and this would be true on a team also, you will usually start on parts of a project that are unknown, and you need to learn as you go. This will mean your initial approach may not be the best approach, and therefore stepping back and looking at what we have is an expected part of the process; think design thinking, where the design process isn't a linear progression but a back and forth as we discover and learn.
To See what is Missing
Finalizing the components for my Layout Builder website was not only good for reviewing what components I already have and what I might need, but it has also been excellent for reviewing the issues of using Layout Builder in Drupal: The issues I find, I would say, are the core reasons behind the Experience Builder initiative, which has since become Canvas.
From the two layout builder pages and the one paragraphs-only single page site, I had created 13 types of components, which are in the table in the next section. This is a good start, and for a lot of sites, this will be enough. With the ability to style components with variations of layout, it most certainly will be enough for a basic website, a quick starter website, which is the main goal of this undertaking.
Above are a few of the component from the layout builder pages. You can view them at the live website Annupuri Chalet and the Coffee Shop concept site. These components and sites will be able to be re-styled in any style you like.
The Connect between Components and Design
The first thing I have learnt in creating this Layout-builder-first theme is that the layout and styling of the components are an integral part of the setup and tightly coupled.
For example, if you build a component one way, style it for that use case, and then try and use it in another workflow, the chances are the styling and layout won't work. This is because the wrapper classes will be different.
An example of this is building a simple block component and styling it for being used inline, but then trying to use it as a global component. You can see this simple example in the following image, that the class for the inline block is definite and will be for all uses, however the global block has a random hash class which is different for all instances.
To learn how to create a new template with set class for all instances of a block, I have written an article on theming the product display with link component illustrated above.
When we look a converting this theme to use with Canvas, we will look at SDCs, Single Directory Components, which may solve this issue in a different way. That said, what is discussed here is still valid for Drupal development as at present Canvas only provides "a fantastic Landing page builder but not connecting it to Drupal's superpower entity concept and their fields... ...if they don't know about the future plans and large picture" https://www.drupal.org/project/canvas/issues/3517216#comment-16328701.
Summary
As long as these things are considered when building, you won't have any issues. Moreover, this step of auditing the components is an important part of that process, which can shine a light on these sorts of issues and then allow you to restrict the usage of component or modify them to allow multiple use-cases or create new ones.
Related: For more on restricting usage of components and restricting them to a content type layout, and also restricting the placement to certain regions with said layout, you can read Restricting Blocks Components in Drupal Layout Builder.
There could be other reasons you will want to do an audit in your design and development process, but these are the three main ones I have found this time around.
In the next section, we will be looking at auditing and classifying the site's components.