TBH if you are a startup and have downtimes, people don't trust you. I know I won't go to a site if it failed on me on the second click because somebody was _adding features_.

If you are a startup and don't have downtimes, you're either building something trivial or a god.

We've actually had less broken downtime since we started doing automated deploys than we did beforehand. It's partially the result of good testing, partially because the changes are just so much smaller than they used to be, and partially because pushing to our master git branch is now serious business.

Another advantage is that when something breaks, the code is fresh in your mind.

If you only deploy in big steps, you have already worked on a few other things and have forgotten a lot about the (broken) code. So fixing things take more time and it becomes more difficult to learn the 5 whys behind the bug.

Imagine this scenario. Peak traffic time in the day and site goes down because of a deployment, an investor sees it and threatens to pull money out. Ad networks that you work with actually see a report where during peak hours their advertisements weren't served, causes of major trouble. I work for one of the biggest sites in my region and take my word for it, uptime is essential and not something left to chance or gods.

Continuous deployments ensure delivery of features and turn around time fast enough for a changing business model of startup and can't be stopped either.

So uptime and continuous deployment model has to happen at the same time.

Deployments should always be automated and revertable. If you think you can run a healthy startup with just about adequate mistakes perhaps you got an easier place to work at :)

You're scenario has nothing to do with CD. In fact, if you aren't using aspects of CD, your scenario is even more dangerous.