The difficult thing about save systems is that they affect all other parts of your game architecture. If you don't design with saving in mind from the start, you are going to run into a dead end.
For example, coroutines are good tool for structuring game logic that runs over extended periods of time, like scripted scenes for example. If you haven't used them before, coroutines are basically functions that can be suspended and resumed later. I like coroutines. The problem is that in most programming languages that support coroutines, there is no way to save the state of a coroutine. So if you've got a coroutine running and you save the game and quit, there is no way to resume the coroutine when the game is loaded. If the coroutine was doing something important, this breaks the game.
For my previous project, I had to write my own scripting language in order to get coroutines whose state can be saved and restored. It was fun to program and definitely worth it, but it was also a lot more work than simply integrating an off-the-shelf scripting language. And in this case I knew ahead of time that I would need my own scripting language to get what I wanted. I didn't have to rewrite anything because I knew the issues I would face ahead of time.
If I had the game using Python coroutines for scripting, for example, I would have had to dump all of that work and start over when it came time to write the save system. And that would have been hell.