Lots and lots of best practice exists specifically to help teams, and especially teams with some normal amount of turnover.
The problems of a solo dev are very different than a dev on a team. Knowledge silos don't exist. Distributed expertise doesn't exist. There's no one to mentor, no shared vision to maintain, no intertia to combat.
I consult on big complicated team projects. I also manage multiple solo projects.
On solo projects, deployment is a script I run from my dev machine. I'm the only person who deploys; anything else would be solving a problem I don't have.
The only "CI" is running the tests before I run the deployment script. I'm the only one who needs to see the outcome of the tests. Anything more would be solving a problem I don't have.
Architecture is whatever makes the most sense to me personally -- which is often miles away from what I would recommend to a client, who needs something any new hire will recognize and be able to work with.
I pay a service to manage backups so I can walk away from a solo project for months and know it's ticking away.
The point is: solve problems you actually have. Don't try to run a "professional" operation by doing what big teams do all by yourself. Big teams have different problems.
'knowledge silos' in a one person team are real: Me today and me from 2 years ago when I set a thing up are different people, and I don't remember that any more than a team mate in a multi-person team would know it. This is where 'professional' approaches can help considerably: using 'standardized' stuff, instead of bespoking everything (even if bespoking is much easier), or making sure you write a TON of documentation for anything you don't do daily...
I'm a fan of the documenting everything even on stuff I wrote and maintain for myself. Because, like you said, old me was way smarter than current me. When he was writing this code, he had the domain space modeled in his head better than me now, 2 years later trying to fix/maintain something.
Probably the best tool you have is somewhere to write your notes down. What you did, why you did it, how to reproduce it. That saves you time in a year or two when you go 'hmm I did something like this before have to do it again because some CPU ate itself'. My old notes have saved me a lot of re-work over the years. Because I had written down what I did so I do not have to rebuild it. I can just skip along the notes and be most of the way there.
This bit seems to hold true across any size team for me. If I have notes I can spiffy them up and make cheat sheets out of them and bootstrap other developers faster. Or if it is just me, my feeble brain will forget odd details that I needed for something.
Absolutely, extensive notes are a huge part of my practice both on teams and solo [1] -- I'm trying to say "solve the problems you actually have" not "when solo, cowboy-code everything like a madman".
Pretty much anyone you can pay to host a database, you can pay to back it up. Amazon rds, heroku postgres, google cloud sql... pick the service that works for you, and they have some affordance for backups. Backups are something I expect, rather than something I shop around for.
In my case I'm dumping + zipping the entire database at the application level. In my case is as simple as adding a library [1], scheduling the job and transferring to AWS S3 (my main application is on DigitalOcean)
The problems of a solo dev are very different than a dev on a team. Knowledge silos don't exist. Distributed expertise doesn't exist. There's no one to mentor, no shared vision to maintain, no intertia to combat.
I consult on big complicated team projects. I also manage multiple solo projects.
On solo projects, deployment is a script I run from my dev machine. I'm the only person who deploys; anything else would be solving a problem I don't have.
The only "CI" is running the tests before I run the deployment script. I'm the only one who needs to see the outcome of the tests. Anything more would be solving a problem I don't have.
Architecture is whatever makes the most sense to me personally -- which is often miles away from what I would recommend to a client, who needs something any new hire will recognize and be able to work with.
I pay a service to manage backups so I can walk away from a solo project for months and know it's ticking away.
The point is: solve problems you actually have. Don't try to run a "professional" operation by doing what big teams do all by yourself. Big teams have different problems.