You are viewing it like an engineer. From a business perspective if you can keep a product stable while growing your user base until you become an attractive acquisition target then this is a great strategy.
Sometimes as an engineer I like the frantically scooping water while we try to scale rapidly because it means leaderships vision is to get an exit for everyone as fast as possible. If leadership said "lets take a step back and spend 3 months stabilizing everything and creating a testing/QA framework" I would know they want to ride it out til the end.
I think you're not following what I tried to convey.
It shouldn't have ever come to the point where incidents, outages, and bugs have become prominent enough to warrant a team.
Either have kickass dev(s), although improbable, thus the second level: Implement mitigations, focus on testing, and have staff engineers with KPIs to lower incidents. Give them them the space but be prepared to let them go if incidents don't go down.
There is no stopping of development.
Refactoring by itself doesn't guarantee better code or fewer incidents.
But don't allow bugs, or known issues, as they can be death by thousand cuts.
The viewpoint is from not an engineer. Having constant incidents doesn't show confidence or competence to investors and customers.
As it diverts attention from creating business value into firefighting, which has zero business value and is bad for morale.
Thus, tech investment rather than debt always pays off if implemented right.
Sometimes as an engineer I like the frantically scooping water while we try to scale rapidly because it means leaderships vision is to get an exit for everyone as fast as possible. If leadership said "lets take a step back and spend 3 months stabilizing everything and creating a testing/QA framework" I would know they want to ride it out til the end.