I'm not sure how you propose that we get an MVP out the door when you just described the entire process of writing software as "doing it wrong." How do you propose to ship a product without implementing any ideas or changing any code?
The point is that you can work fearlessly, confident in your ability to roll back if it turns out you've gone down a garden path. Even if you the probability of doing so is low, the cost of running version control is so low that it's really a no-brainer.
>How do you propose to ship a product without implementing any ideas or changing any code?
Well, that's an absurd oversimplification of my point, but it's really irrelevant; the entire topic isn't really worth the effort of the conversation. It was just a suggestion.
If you can't sleep at night without version control, then clearly, implement from day 1.
Version control works really well once you have something (anything) that is actually worth rolling back to. For me, this moment is a version that is "usable". That's when I create my first repository and commit. Prior to that, it just doesn't really make much sense to me.
I've seen so many instances where the problem was more "Shit I forgot to commit that" in early stage development that something like Dropbox can be so beneficial that it pretty much replaces any benefit at this particular point. If you commit on every save, then I suppose you wouldn't have this issue, really.
I have to echo the pro-VCS crowd. I've had so many times, even in tiny projects, where I've broken something in a really difficult to reverse way (or maybe I'm not sure how exactly I broke it, but it used to work, damn it!), and being able to simply revert with a "git reset --hard HEAD" is amazingly helpful.
The point is that you can work fearlessly, confident in your ability to roll back if it turns out you've gone down a garden path. Even if you the probability of doing so is low, the cost of running version control is so low that it's really a no-brainer.