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.