I have the same issue. I personally recommend to do "things that don't scale". Just continue to pump out features and make more money. Do not worry at all about scaling, in fact, ignore it.
Why?
1) It's extremely unlikely that you will actually hit a major issue because of scale or wrong software architecture which will bring your system down
2) Even if that's the case, it will probably be easy to fix it when it happens because the issue will be clear, whereas in hindsight you are trying to solve 1000 architecture issues without actually knowing what will come up
3) Even facebook and google probably had problems in the beginning of their startup life. Even if your system crashes and is down for a day or two (for non mission critical apps obviously), it's not the end of the day, nor will in matter in the medium or long term, and probably not even in the short term. I can tell you I worked at a unicorn startup with government and bank clients which are usually the most strict, and that kind of stuff happened all the time... so unless it's mission critical and/or you are dealing with extremely strict customers, it doesn't make a difference
4) After coding a bunch of features, patterns emerge by themselves. Very often I do early optimizations that end up not actually being so useful since I have to add new features that work in a way the current well thought of architecture doesn't allow. I think I got it from Joshua Bloch's book or ppt/pdf on designing APIs that it's better to actually work with 3 (magic number, but I attest from personal experience that it should really be a minimum) actual use cases before designing an API. Same for architecture, by focusing on it before the code, it ends up having to change later on anyways, and we end up optimizing for non issues and loosing flexibility where it is needed. However, after you code enough features, you see where you've repeated yourself, that's not a major insight, and abstracting those or encapsulating those repetitions that happen 3+ times is now trivial. You can then choose when you code your Xth (s.t. X>3) feature and you've encapsulated the repetitive code whether to refactor the first 3 features to use the new implemented encapsulation or just leave it as is because a) it takes time to refactor and b) if it works, don't fix it, though you may prefer to simply and quickly replace the repetitive code by whatever construct you made to keep the code consistent and so that the code itself should serve as an example of implementing features for yourself or other programmers in the future.
5) To continue on the 4th point, doing the architecture without knowing how the system will evolve (which is really impossible in software, we do not know how customers will react to features beforehand and what the needs will be) is basically impossible. I think that's where the stress comes from: You want the architecture to be good, but there's always a "it could be like this" "or the need could be different like that" "or we could have 5 different needs". It's endless, the software can evolve in so many ways and it's impossible to predict, so which way should you optimize? And each design takes time, hence the stress: you don't ave enough mental/time/etc resources to deal with all the potential needs. However, if you switch that to "I don't need to solve it before it comes up" all the stress goes away, and you can just try out new features.
If you do this, your revenue will (hopefully) grow, you will be more productive, your system will end up more robust and have better architecture (because it's always easy in hindsight and usually impossible beforehand), you will avoid stress, and be happier!
Happy coding, all the best :)
PS: The examples are the same usually for horizontal or vertical scaling and splitting things into microservices, and for a bunch of issues, I just picked a simple idea, but I do believe it's a general approach what I said in point 4.