If you genuinely want to become a software entrepreneur for the rest of your life, you just have to pay the price of learning horizontal scalability once and reuse your knowledge for the rest of your life. Thus, my opinion only applies to dedicated software entrepreneurs.
In my experience, horizontal scalability isn't difficult if you are actually a software engineer. Actually, I wouldn't hire any programmer who can't understand horizontal scalability quickly. I'm saying this as someone who's not particularly smart.
You don't have to implement everything in the early stages, but you have to know distributed design and implement some of it so that your software isn't hindered severely later when you actually need to implement more scalability techniques.
Definitely, learn distributed design, and implement it gradually over time. Don't paint yourself into a corner by implementing things that can't be scaled later.
For example, you don't have to deploy a load balancer from the beginning, but make sure your software can work with a load balancer later. That means stateless design. Stateful design can't work with a load balancer.
Distributed design is not that complicated in small scales. It's not that difficult to write. It's not that difficult to manage when the scale is small. If you think it's much more complicated, then you are not a software engineer, or you are an entry-level developer who just started learning things.
It's possible to design a relatively simple distributed system.
If I want to write a web application that can scale later, I would rather start with a small-scale distributed design which can be scaled easily later.
If you actually understand distributed design, you can teach it to those who are willing to learn.
Figma was funded by a huge financier and could afford to spend more than 5 million dollars on horizontal scalability alone. Figma's horizontal scalability design isn't particularly good because it started with vertical scaling. I also wouldn't count on being given more than 100 million dollars in investment.
If you really had a lot of money, you could pay for rewrite of the entire backend, but you will have to stop the service.
I don't like the idea of bolting horizontal scalability on top of a vertically scaled "live" production system on the fly. Figma spent 9 months and millions of dollars on such a live surgery. Even if I had money to pay for that, I prefer not to do that. I'd rather avoid performing a complex surgery on a live system on the fly. Training developers on distributed design from the beginning is cleaner and simpler. My aesthetic sense doesn't allow me to choose a months-long messy live surgery. That's why everything in my life, including my room is clean. The months-long messy live surgery feels like seeing a messy room.
Other companies already pioneered distributed system design so that I don't have to. It's not like I have to spend 10 years on researching a distributed system design before I can write a line of code.
Usually, if you can pay the costs upfront without losing speed, you should do that. I wouldn't pick a business model that forces me to do things at break-neck speed and thus accept a lot of mess. I understand that nothing can be slow in business, but I also don't want to sacrifice neatness to get break-neck speed that allows me to churn so fast I can run a company that loses money for years. I'd sacrifice initial speed to a degree in order to gain speed later. I believe I can maintain neatness and enough speed if I genuinely try hard.
I fully aceept the fact that it's going to be harder to take on more initially, but if I postpone certain concerns, I will have to work harder later. I'd rather work harder now. I don't believe starting with a distributed design is going to hurt my company a lot or kill it. I'm a decent software engineer, and I can retain a person like me without paying too much. I believe any software engineer who is not stupid can learn distributed system design quickly if they are given the right learning materials. I'm not a super genius who can't be replaced.
Usually, you have to deliver at break-neck speed because you have employees without any revenue or a deep financial reserve. If you are starting alone while you do a part-time job or spend your own fund, you still want to be fast, but you don't require breakneck speed in order to pay employees as soon as possible.
In my experience, horizontal scalability isn't difficult if you are actually a software engineer. Actually, I wouldn't hire any programmer who can't understand horizontal scalability quickly. I'm saying this as someone who's not particularly smart.
You don't have to implement everything in the early stages, but you have to know distributed design and implement some of it so that your software isn't hindered severely later when you actually need to implement more scalability techniques.
Definitely, learn distributed design, and implement it gradually over time. Don't paint yourself into a corner by implementing things that can't be scaled later.
For example, you don't have to deploy a load balancer from the beginning, but make sure your software can work with a load balancer later. That means stateless design. Stateful design can't work with a load balancer.