All of the products and sites I have launched over the years have one thing in common, they were all delivered differently, and after having the chance to look at all of them, I would love to reveal the one step-by-step guide to ruling them all. Unfortunately, what I have discovered is that it cannot exist. That is because as unique as people are, so too are websites.
I have discovered and rediscovered the "right" way to build and ship software many times over now. I have found some ways that were near-religious in how they applied certain practices (Coding standards, A/B Testing, Automated testing, etc) only to find out that the lock an solid solution quickly fell apart when applied to some other tool.
In my profession, there are arguments carried out, sometimes decade-long wars over things as small as Tabs vs Spaces in code. It really has become no surprise to me that people get really attached to development and release habits. However if shipping so much software has taught me one lesson, it is to be flexible. Different methodologies can optimize for different goals. All of them have their strengths and weaknesses.
First, take a look at who your customer will be
In order to know what the "right way to develop software," will be you need to learn what is most important to the market you are serving. Having this knowledge will help you reduce the chances of making costly or time-consuming mistakes.
The chances are that if you sell software with a high price tag, then you are selling to businesses or customers who are buying based on their needs and the more expensive it is, the more mission-critical it is for your customers. This means you will need to think more about having a predictable schedule and have emergency procedures documented when things go wrong. In these situations, most customers care more about knowing and having a predictable experience than speed.
If your customers are not enterprises or large businesses, then as you charge less and less your market will go from predictability and schedules to more about one that can serve higher volume and will involve smaller businesses or consumers. For these services/products, you need to focus more on how quickly you can get new features out. The influence of an individual customer is so small, that you may deprioritize a niche platform or bugs that are only affecting a few people.
The danger here is letting yourself stop caring about quality too much. If your product is inexpensive or free, people are using it because they want or like to. Not because they have to. This historically means that user experience is much more important to the customer.
Decide how you will deploy and how much you are willing to risk
There are a lot of ways to deploy software and code, all of them have trade-offs between time/ease of developer use/security of the platform. You will need to decide what is most important to your product.
Do you need reliability?
If you need your site to be 100% up then you would want to leverage some sort of automated system, that included test coverage to prevent bad code from brining your site down. This sort of system requires upfront planning and is usually restrictive.
Do you want efficient testing?
You can set up systems and use tools like behat or others to catch around 70-80% of the bugs, while this will prevent things from getting through it will slow down your release speed because you will need a team member to create the tests at the start of development.
Do you want a quality UX design?
If you are looking more for better UX design, then you would want to expose and develop quick feedback loops by creating and releasing prototypes in production for limited number of users to see how it works. This has a lot of work upfront to do in order to make it work right, but can lead to a lot faster improvement in user's experience and adoption of your service. Additionally, it can be a way to keep people coming back more frequently.
Preparing for Launch day
A large percentage of developers underestimate how much time something will take. This is oftentimes more because it is hard to estimate complex interactions between various systems. So it is best to try and take your estimate and add a couple of weeks to a month at the end of it depending on the size of the release. I tend to recommend to users to add at least 25% on to the estimate the team comes up with. Then add another 25-30% to the estimate to allow them to approve and plan marketing around the release. Adding this time while it can seem like your delaying is the best surefire way to release without a headache. Keep the deadlines for the developers the same, but make sure you give your business and users padding for the unexpected challenges that the team may face.