I'm assuming that the application is a Laravel based application. If so, identify the version of Laravel used in the application and follow the Laravel documentation for that version to get an understanding of how it all works. If you are a visual person like myself, I would start by navigating the site from the homepage and attempt to identify where in the code it is written. Using developer tools from the browser could come in handy. Once you are able to identify this, try making minimal edits to confirm (ensure this is being done on a different branch). Make your own notes from there.

For Laravel Applications, i've always found it easier to move from the pages to the routes and then the controller logic. Then the relationships on the model too can you help you understand how the database tables are linked together. From the Database Relationships you can better write your own understanding of how the system works

Unfortunately this seems to be more of the rule than the exception for almost every medium to large project.

I suggest that you use the following approach:

• web.php
  • This will help you see what is being used, what middleware is being used, the route names, Livewire used, etc.
  • Take a look at some of the Controllers/Livewire to get a flavor of what they are doing and how. Do they contain comments and are the comments up to date for what you are seeing.
• Register for the app and use it. Take notice of the most important areas being used and start diving into them.
  • Take notice of the URLs being used, track it down in the web.php file to see what Controllers, Livewire, etc components being used.
• Take notice of the add on packages being used, whether they are used globally or in specific parts of the app.
  • Livewire, Tailwind, mapping software, handling of dates, etc.
• Trace how a major section of the app is constructed: Controller/Livewire, blades, included files / blades, javascript components, menu system, etc.
• What did they use for Version Control. This may help to see what sections are being maintained more then others. It seems that the most importance areas will have more work than the others.

Every developer has their own signature, the way they write their code, their implementation, their usage. I found this to be helpful in determining how to look at and expectations of their code. Two people reading the same manual will normally take 2 different approaches, with some of them being quite different. Knowing this will potentially give you a decent idea of what is being done and how.

Figure out the roadmap and go from there. Please note, the above is not a comprehensive answer, but I hope this will give you a good start. Welcome to the world of maintenance.