A pattern I've seen from joining a lot of Laravel projects over the years is that the current developers often lose sight of the pain points in the project. They become numb to them.
For example, a test suite that has a few flaky tests. Instead of fixing them, they just re-run the tests when CI fails once a week.
Or it could be that the migrations don't accurately reflect the production database schema. Instead of normalizing it, and then enforcing that all future changes are done via migrations, they pass around prod schema dumps.
When I join with a fresh perspective, I see the pain clearly, because I'm feeling it all at once while I onboard. So instead of just enduring it, Aaron and I will fix those things.
What makes it even worse, often it only takes us a few hours to sort out an issue that might have been plaguing a team for years.
It's not that the team couldn't fix it, but it just never became a priority.
I understand the demands that come with juggling priorities, but my advice is the next time you feel a "paper cut" on your project, time box 30 minutes and see if you can fix it.
Time boxing is important though. You don't want to derail the main task you're working on, but a short diversion to benefit the health of the project is a reasonable tradeoff. Your team will appreciate the quality of life improvement.
Here to help,
Joel
P.S. Is your project's README the default one that Laravel installed? We always write docs when we work on a project.