[venture_lol]

There is nothing wrong with planning for scale and for microservices or whatever appropriate architecture from the start.

It does not take more time to design properly from the get go.

That, of course, assumes you have a CTO and a team capable of their job :)

[dasil003]

Yes, if and only if you know exactly what you need to build and how big the scale will be from day 1.

What usually happens is the first thing you build is wrong, and you need to iterate aggressively on not just the software but the entire business concept. Once you have product-market fit, then you are in a position to design an optimal architecture. If you go microservices before that, you are adding unjustifiable overhead, which will inarguably slow you down compared to a monolith when you are in the 1-3 engineer phase, and don't fool yourself about that.

[venture_lol]

I frankly have no idea what you are talking about. You are making wild assumptions that monolith are better just because...

It will all come down the the experience of the team, esp. the leadership - the managers, the leads.

A strong, experienced, mature and effective leadeship will enable a team to perform "magic" and set the right technology foundation that will prove its worth as the business grows over time

[dasil003]

I am not making "wild assumptions", I'm putting a stake in the ground that a monolith is lower overhead than microservices, and thus better when you need to iterate quickly, which is always the case in early stage startups.

You're making fantastical, hand-wavy claims that belie the hard tradeoffs that need to be made to get a startup off the ground. Microservices absolutely add complexity and require more effort to set up correctly and orchestrate, pretending that experienced leadership makes that problem go away is dangerously idealistic. What experienced leadership gives you is good judgement on whether the overhead is worth it given all the factors at play.

The way you speak about the team, and different roles makes me thing you've maybe worked at "startups" that are actually established businesses with traction which like to retain the mythology and allure of being a startup (perhaps to justify lack of profitability). Things are very different in a true startup where the tiny handful of employees all must wear many different hats.

[taurath]

The point he's making is the technology foundation can be built for the wrong product or the wrong market. After 2 full product reconfigurations or pivots requiring a TON of code being dumped you will wish you didn't have the overhead of building infrastructure with the first product in mind. In the end, the base reasoning for the foundations being built the way they didn't hold up in production.

Building something quickly that can be broken up over time is the best way to an MVP, and you can deal with scalability issues when you HAVE scalability issues. I consider scalability to be a good problem to have, because by that time you have actual traction.

If you are a bigco with a big marketing budget in a field in which you already have experience and business then by all means scale to millions of users at day one. Don't take on the cost of it in a startup, because the problem is TRACTION not technology with regards to scaling.

[venture_lol]

You are making assumptions about both the premise and the conclusion :)

Designing and building for scalability, flexibility, availability, etc does not mean going all out to boil the ocean and then find that you attempted to boil the wrong ocean.

If that did happen, you got the wrong team :)

[taurath]

Sorry about the assumptions. It did happen, and it was the wrong team :)