You describe many technical solutions so I think you have that bit covered. The next step would be to consider some broader questions like
- What is quality?
- To whom is this quality?
- Is it important to them?
- Why is it important to them?
- Do they really want to pay for it? Less or more than they are now?
- Would they rather pay for something else?
- Do we collect statistical evidence of quality, as defined by the customer?
- When we address problems, are we making local fixes or large system-wide changes like adjusting the organisational hierarchy to prevent entire classes of problems?
- Do we believe the people we have hired are the key to quality?
- Are the people working for us happy to do so? How do we know? How soon will we find out if someone is no longer happy and afraid to say so?
- If the economy goes down the toilet, what expenses do we scale down to maintain the people we have hired?
- Are we able to continually reduce costs and prices due to quality improvements?
- Are we chasing ghosts sometimes? Or do we only take action on real problems?
- What are threats to our current level of quality?
- How do we Institute a culture that ensures quality 3 years from now? 5? 10?
- is our level of quality constrained to the code, or do we have high quality relations with the customer too? How do we know? What is the biggest point of improvement in customer relations?
- Is our documentation high quality? Installation instructions, user guides?
- Do we have high quality in our relationships with our suppliers? How do we know? What's the biggest point of improvement?
- If we run into trouble with one of our suppliers, will our quality be affected? How can we avoid that?
There's a huge amount of literature on quality control. Much of it is from the 1960's or before, but it's just as important today. Deming's 14 points and deadly diseases are a good start, but I'd recommend continuing with his book Out of the Crisis, following whatever references you like (Shewhart, Juran, Taiichi Ohno, Reinertsen, Wheeler, a little depending on where you want to start.)
The general principles are:
- Consider not just the code, but the entire system around it (rest of your organisation, your competitors, suppliers, customers, regulations and standards, and relations between the above.) Make fixes where they are the most effective, not where they are most convenient.
- Use statistics to tease out signal from noise. Overinterpreting noise is a great quality killer.
- Adopt an experimental mindset throughout the entire organisation. Establish hypotheses, try them out, adjust based on results. This goes especially for the highest management. (See above about statistics.)