Your scenario can be a lose-lose situation as it applies to the question. Speaking from experience, you can do the “agile” approach do fail fast, release faster, but with no buy-in from leadership to address the breaks in the future, your compounding problems on problems.

So, short-term, you have happy leaders who see releases as they want, and unhappy devs who are in a shitshow of code.

Long-term, if your startup is either acquired or starts to grow a strong revenue stream, leaders need to appease their new owners or their influx of new customers, and you can’t slow down because either a.) the new board needs to be impressed to justify their large acqui-investment, or b.) your new customer base is too big to risk losing. So you keep building on bad code, maybe squeezing in a few skunkwork refactored that only the dev peer reviewing and QA know about, and accept any delay on release as the result.

The approach should be somewhere in between, ideally with the engineering team being empowered to tell leadership “yo, we have a bomb of bugs just waiting to burst if we add one more feature with duct tape, let’s prioritize time to address it”.

If leadership doesn’t trust your team, then you have bad leadership.