Yeah, for something like backups, I like having short and easy to test/debug scripts rather than "all in one" scripts like Ola's. That is just my preference, especially since Ola's works with so many different backup solutions and I only have 1 at my workplace. I'd much rather have short and easy to manage/debug scripts in my environment for something as critical as backups.
For the maintenance stuff (statistics updates, index maintenance, checkdb, etc), I'm fine with using a script from the internet as those are all baked into SQL so don't need to worry about an update to SQL Server or a backup tool causing the task to fail. That being said, those types of maintenance task scripts are pretty easy to write myself so I did it all on my own. Resulted in multiple stored procedures (one for backup, one for checkdb, one for statistics updates, one for index rebuild, one for index reorganize, and a "master" procedure that calls those other ones). We use RedGate SQL Backup for our backups, so all of my backup scripts are aimed at that tool. And if any of the stored procedures fail, it is a short and easy script to dig through and fix. Had the index one fail once on a vendor database due to them deciding in an update to turn OFF page locks on their tables and indexes, so my index reorganize tasks failed. Something fun - Maintenance plans will fail at this too. But I could fix it as I knew what my scripts did and I knew why it failed.
Also, not sure if you are doing this or not, but my advice is to TEST your backups regularly. Do a restore of the backup and make sure you are running CHECKDB after doing your full backups. Depending on how much downtime you have and how long the CHECKDB runs for, I'd recommend running it nightly. The restore is to ensure that the backup was ACTUALLY successful. Just because it was written to disk doesn't mean that network or SAN gremlins didn't fiddle with bits and corrupt your backup (or early stage disk failure, SAN firmware bugs, etc) and CHECKDB will tell you if the database is corrupt or not. A corrupt database will often still backup AND restore successfully bringing the corruption along with it.