Mostly it depends on a) what level of quality you need, b) what are you currently doing for quality control, and c) what other alternatives do you have?
On a): What is your customers bug tolerance rate? What part of the codebase is this? Most people will be ok with a few application crashes or a feature not working in some edge cases but be irate if you corrupt their data. Are you just trying to MVP or prove an idea? Is the app going to be around in 10 years etc? Are you building a framework or api that is going to be a building block or a user facing app? Huge difference.
On b): If you are already unit testing then that's 30-40% of dev time. Add another 10% for integration testing and you are already at basically half the effort being quality control. Add another 25% of total time on top and suddenly you are looking at spending 60%+ of the dev effort on quality control. Is that a good use of time? Depends on a) and c) :).
On c): For example perhaps you would be better off getting rid of code review entirely and using the savings to hire dedicated QA people. Or perhaps formal reviews would work better. Or maybe more time on design or talking to your customers. I'd personally rate all three as more effective.