[n_ary]

Counter argument is that, you do not know whether your system will go big next week. If it indeed does, now you do not have the Google/Meta/Amazon engineer legion to immediately scale it up without losing users[1]. Also, a gambit of scalable system initially helps to solve the later death-march, when management wants to ship the MVP in global production and then come howling when users are bouncing because the system was not designed for scale.

[1] Unlike early days, users are very quick to dismiss or leave immediately if the thing is breaking down and of course they will go rant at all social media outlets about the bad experience further making life hell for "build things that don't scale".

[mewpmewp2]

Counter point - even if you spend more time on scale and system setup you will still be prone to failure without having this scale tested and stepped up progressively.

And I think ironically you are more likely to get higher scale if you spend less time on scaling, since you spend more time building other things that users care about.

And frequently if focusing on scale, you will run into bugs that you wouldn't if you would just use a simple one box monolith. Your incident resolving might take longer with a scalable microservices arch because debugging and everything becomes much more complex.

You have limited resources where you are assigning skill points to your character. But the thing is, if you do a more complex arch, it will keep taking away those skill points not only in the beginning but over time.

[passion__desire]

The other point is what if your Company's exit strategy is dependent on going big. Then it is pertinent that you plan for that 0.01% chance because there is no other exit.

[brtkdotse]

”I better buy a smaller clothes now in case I suddenly lose weight next week”