Probably the first thing that should be acknowledged here that being good CTO isn't the same as being a good dev.
I'm not a CTO and never have been, so feel free to completely disregard my advise, but from what I've observed being a good CTO is far more about communicating effectively with the rest of the org, understanding business requirements and ensuring the development team is equipped to solve problems than being a good dev. To some extent you also need to be available to unblock devs when there are key decisions that need to made at a higher level.
In a smaller company you might need to wear multiple hats from time to time, but when you're acting as a CTO your job isn't to be a good dev and to do things the right way, but to ensure you have the right devs and architects in your team so they can tell you the right way to solve problems. The most you should be doing is approving and guiding their decisions. If you feel you have something to offer as a dev then by all means, share your opinion with the team, but your not there to be a dev, you're there to be a CTO.
It sounds like you're taking too much on honestly. You can't be expected to know everything or be an expert on everything technical problem that comes your way -- that's not what a CTO does. A CTO just needs to have a solid high-level understanding about how things come together and delegate everything else.
I think first you need to decide if you want to be a full-time CTO or a CTO who is also a developer. If you're going to continue to be a developer while being CTO then you'll probably just need to accept you're statistically unlikely to be the best developer on the team to solve every problem and therefore from time to time you're going to do things wrong and you're going to need to seek help and feedback from other devs.
For what it's worth a small-medium sized company I used to work for had a CTO who was also a dev (he was the first dev), but by the time I joined the team he was also the weakest dev there. Thing is, he acknowledged that and that's why we were there. He picked up a few dev tasks from time to time where he could and when he had time, but otherwise he would trust us to tell him the right way to solve problems and let us get on with it. He was a great CTO in my opinion, not because of his dev skills, but because he trusted us and gave us the resources we needed to get our jobs done. There were many occasions I needed help from other devs on the team or even external resources and he would always make sure that help was available to me so I could do my job well. That's your primary role as CTO in my opinion. You're not suppose to be a good dev, you're just suppose to ensure you have a team of great devs who have everything they need to be great devs.