I don't really get this line of argument

Or at least it's not engaging with the obvious counterargument at all - that: "You may not need the scale now, but you may need it later". For a startup being a unicorn with a bajillion users is the only outcome that actually counts as success. It's the outcome they sell to their investors.

So sure, you can make a unscalable solution that works for the current moment. Most likely you wont need more. But that's only true b/c most startups don't end up unicorns. Most likely is you burn through their VC funding and fold

Okay stack overflow allegedly runs on a toaster, but most products don't fit that mold - and now that they're tied to their toaster it probably severely constrains what SO can do it terms of evolving their service

▲

macspoofing 2 days ago | parent [-]

>So sure, you can make a unscalable solution that works for the current moment.

You're making two assumptions - both wrong:

1) That this is an unscalable solution - A monolith app server backed by Postgres can take you very very far. You can vertically scale by throwing more hardware at it, and you can horizontally scale, by just duplicating your monolith server behind a load-balancer.

2) That you actually know where your bottlenecks will be when you actually hit your target scale. When (if) you go from 1000 users to 10,000,000 users, you WILL be re-designing and re-architecting your solution regardless what you started with because at that point, you're going to have a different team, different use-cases, and therefore a different business.

▲

contrarian1234 a day ago | parent [-]

Do you have actual examples of this?

Your solution is to basically do a re-write when scale becomes a problem. Which is the textbook example of something that sounds good but never works

On the other hand I can't think of a business that failed b/c it failed to scale :)

	▲	zelphirkalt a day ago \| parent [-]
		Because you never read about their failures like that. For users they might simply become not interesting, because they fail to deliver good features reliably, because, unbeknownst to the users, they are busy working on their scalable architecture all day. The final statement rarely is that they over-engineered it and this failed to build an interesting service.