[dub]

Seems like you feel that establishing data access patterns that have the possibility of scaling up to 100x more users requires an additional 3 weeks of initial developer time

I'm not sure I agree that an engineer experienced in building scalable systems will need 3 extra weeks to pick a schema and data access pattern that's scalable.

You don't have to actually _use_ spanner or cockroach or vitess in your initial prototype if you don't want to, but it seems entirely reasonable to have an _idea_ of what the story would look like to migrate to a horizontally-scalable approach if product gains traction so it doesn't end up being a multi-year project later.

[shynrou]

Most teams I have encountered so far don't have an anyone that experienced with scalable database systems. So you have to choose the best you can do at that moment without loosing your momentum. When more users come more funding will come and you can hire someone who can repay the technical dept chosen before.

[dub]

Agreed that it's a result of not having people experienced with building systems at scale.

That's not a technical choice since the person writing code wasn't aware of the options, so it's a business choice. How good of a business choice is it, though?

We all know at some level that a well-intentioned but inexperienced engineer can make a decision in an afternoon that will take weeks or years to clean up. I often see junior engineers spend several days over-engineering something that a senior engineer would have done simpler and better in a fraction of the time. I don't think it's a given that junior engineers provide better return on investment early on that a senior engineer.

Getting some worthwhile feedback and advice from a seasoned engineer doesn't need to cost a fortune in up-front cash, and personally I think it'll pay for itself. You either compensate them with stock or hire them as a temporary or part time consultant.

[q-big]

> When more users come more funding will come and you can hire someone who can repay the technical de[b]t chosen before.

The problem is rather that the technical debt is often not repaid.