Keep track of your project's external dependencies

Over the years, I've learned the importance of carefully tracking all the various services and tools used by a project, but that are external to its code.

For example: monitoring services, email deliverability tools, project management tools, and so on.

These services tend to accumulate over time, and you may even switch from one tool to another as your needs change.

Because these types of services aren't called by code, they won't be referenced in the .env file. Therefore, you can't rely on that to remind you of what is in use.

Why is this important?

I recently was asked to shut down a very long-lived client project (over 10 years!), and having this information recorded in one place made this significantly easier.

In my case, I use Obsidian for these kinds of client notes, but it could also make sense tracked in a section of your project's README.md file.

Regardless of the specific documentation format, I was so grateful I tracked all these tools, both paid and free, over the years, and had a complete checklist for shutdown.

But even if you never have to shut down the project, having all of these external services and tools documented in one case is still useful. It's a place you can periodically audit, to make sure you're not wasting money on unused tools. It's also very convenient when onboarding or offboarding team members to grant or remove access.

As with so many things in software development, being diligent with documentation a few minutes here and there over the life of a project pays huge dividends.

Here to help,

Joel

P.S. Another area where diligence is important is data validation. That's one of the messages we weave through our book Mastering Laravel Validation Rules. It will improve the security of your application and the quality of your data.