I agree with most of what you're saying. I think at least the first 2 engineers in the team should be experienced in the stack. And nobody inexperienced should ever be making initial design and architecture decisions.
The commenter I was responding to was saying it takes years to learn that stuff and I disagree with that. Smart engineers can get up to speed in a few months with an experienced team.
In a more established company that works well. In very early stage startups? It can, but it's more of a risk. Most early-stage startups are not well organised and the typical situation is that you can do whatever with fairly little oversight. The 3rd, 4th, or 5th engineer can still make a right mess of things.
This applies even more so if your country has fairly strict labour regulations by the way, where it's hard to fire people; bit of a different discussion, but not completely unrelated here.
That's why for me having a strongly technical / expert-level co-founder is really important. I'm lead engineer and the first non-founder coder at at tiny startup, and I just spent several months rebuiling the entire application after spending several more months of grappling with the mess made by the weakly-technical CTO. This is very much not what a super-early startup should be spending it's time on, but there was no way forward with what we had.
If you're a senior engineer joining a startup where the initial application has been built by a non-technical (or weakly-technical aka junior-dev level) person then beware! It may be much, much more of a mess than you are expecting. Go in with your eyes open. You might not have the luxury of fixing it properly, as I have just had. So it better be a promising startup.
The person that built the entire application was very weak technically. I'm pretty sure the motivation for bringing me in was that I would "fix up" the entire mess. There was no documentation, no tests, and tons of code copy/pasted everywhere.
I spent a year trying to improve it, but for every thing I'd clean up, the original engineer would write twice as much new code without consulting me. I tried to get them to do architecture reviews and code reviews, but everything was always an emergency that needed to go live immediately.
If I ever thought about joining a startup that small again, I'd make sure I got to look at a representative chunk of their code base first. And if it looked like it needed a lot of work, I'd grill the existing engineers hard to make sure I can actually do what they want me to do.
Sorry you had that experience. I was also planning to quit if I didn’t get my way on having a rewrite (though I never told anyone at the company my plans). I was lucky that the CTO was not unaware of the weaknesses, and listened to me. And now they mostly stay out of the codebase. It could have gone the other way.
I've been at a startup where this was the case, but they didn't start over, and it was a disaster that, at least partially, was the cause of the failure of the company. Props to you for making the difficult, but correct, choice.
The commenter I was responding to was saying it takes years to learn that stuff and I disagree with that. Smart engineers can get up to speed in a few months with an experienced team.