Ask HN: How many companies fail to engineer for scale?
And how many over-engineer for scale that never actually happens?
You can get a long way with a monolithic architecture and a reasonably good database that you don't abuse nowadays (40-vcore servers, hundreds of gigs of RAM, terabytes of fast SSD). And in the face of getting a product out as quick as possible, not making hugely awful decisions in how to store and access your data is key. 10% more time thinking about these problems saves you several orders of magnitude down the line fixing and solving scaling problems.
If you really scale, you're going to rewrite most of it eventually anyway, but having the data stored in a sane manner makes all that easier anyhow.
This is the biggest problem with trying to scale too early - you take the focus away from your product. The reality is that most businesses will not work out. Instead of focusing on scaling something that may never sell, you should use the tools that allow you to iterate on your product as quickly as possible - where reasonable.
As stated above, if you end up needing to grow the business, all the code will eventually be rewritten. The data, however, will likely be much more expensive to change. Put some time into thinking about your data model, but otherwise focus on building your product.