Look, as one of the rare people that actually likes doing QA, let me paint you a picture of how things'll go.<p>If you don't do it, you'll have no enforcement arm to make devs care about maintainable infrastructure or Quality of User Experience. Your tech stack will be driven by whatever whizbang your devs that actually matter want to do will-o-the-wisp style, and over time, as complexity ramps up you'll be left with a bunch of teams that know their microcosm, but not how everything fits together, and next to no one willing to actually dig into the shittier parts of the codebase.<p>If you hire some QA, but only enough to keep every one of them tasked 100%, no downtime, no training/learning time, no redundancy, you've got QA for maybe 1 and a half to 2 years tops. Your entire QA group will see through any lip service that management pays to Quality Assurance, no long term investments in knowledgebase, preservation of tribal knowledge, or keeping the Quality bar raised up higher than it's original set point as people start attritioning out.<p>This will start to be reflected in an increase in prod issues, slower defect resolution, poorer user experience, decreased morale, more miscommunications over time, and loss of cohesion.<p>My point is this. Quality is either something you commit to, or you don't. You can pay it lip service, but your customers will know you didn't.<p>I've seen it played out time and time again. Don't take my word for it though. Spend a couple years to paying attention to rediscover it if you want; just remember whose responsibility it was for making the decision to not make nice things. Your QA people are the only ones charged with being an organizational conscience on the behalf of your users. Proceed without it at your own risk.
Nothing that's said there is wrong <i>per se</i> but the writing is biased toward trying to sell the reader on buying their QA products and outsourcing. Which is fine, it's their corporate blog, but just take it with a grain of salt.<p>Personally I've lost count of the number of no-code QA tools over the past decades I've seen that fail to deliver on their promise of painless QA automation.
That speed vs "fixing it" after an embarrassment trade-off is a hard one - def seen many folks hit that. Avoiding being / having to be reactionary in the first place is probably the smartest, if you can pre-plan!