A few years back I took on a hard project: complex scope, a demanding client, and a talented dev team that was being tested for real for the first time. Everything was fine until delivery season arrived, and with it the client's own testing. After a lot of back and forth, we went live a few months past the deadline. Our fault, but also the changes the client kept asking for along the way. And so the project stopped being a project and became continuous maintenance.
We had a CI/CD pipeline and reasonable test coverage. The contract is what was peculiar: in maintenance, the hours spent building a new feature were paid; the time spent fixing bugs was not. And there was no dedicated QA. The same team that wrote the code tested what it wrote, by hand and automated.
And the bugs we had. Just remembering gives me chills. Nothing serious, but bugs that pile up scratch away at your credibility with the client. The last straw was a Friday deploy. We shipped, we went home. The damage only showed up when we opened the email on Monday, with the client furious, and completely right. An API route had broken, the tests didn't catch the case, and the integration was down the whole weekend. A one-line fix. But we left the client hanging, and that was unacceptable.
QA was treated as a luxury
Up to that point, QA was a luxury. Whenever I raised it with the tech lead, the read was that we didn't need a dedicated team. Leadership didn't see the need either. That weekend changed the mindset for good. The same week there was a meeting, and I heard all of the frustration: that our team was useless, that we should be ashamed of our code, that the contract was at risk. I listened, and I swallowed hard. When my turn came to speak, I agreed, I took responsibility, and I asked for one thing: "Give me a chance. In one month we'll get this project back on track."
The team was good, the code wasn't bad. But what weighs is the client's perception. We had an innovative product in our hands, it took an enormous amount of work to ship the features the client asked for, and we were short on people inside to validate everything. Every project has a QA. Our problem was that, until then, the QA was the client. That had to change.
A QA area is born
I left the meeting with carte blanche to hire and put the house in order. Bringing in two QA people became the priority. With the hires made, we got to work. I added one more dev: while one shipped new features, the other fixed the bugs the QAs found. That single adjustment was enough to balance the project financially. And here an important penny dropped: remember the contract, where a new feature was paid and a bug fix wasn't? With the QAs filtering out the problems before they reached the client, the team spent less time putting out fires and more time on what actually generated revenue. QA wasn't a cost. It was revenue.
Deploys also stopped happening at any random moment. We moved to a fixed day of the week, well communicated with the client. That predictability made a huge difference in our communication, especially when a deploy needed a rollback. Once in a while something still broke in production, scenarios impossible to cover in staging, and that was okay. The first month was heavy. By the second, the app was more stable. From the third on, running smoothly. The QA area proved its worth, doubled in size, and took on other fronts, new products and tools.
Looking back, I see how big that moment was, and I'm glad it worked out: the client's trust held, and where it had been scratched, it was rebuilt. Building a QA culture takes time. But every small win, every satisfied client, every bit of praise lays another brick of it. The team that had no QA became a team that can't live without one.
Huge thanks to every QA I've had the luck to work with, and to Cantinho das QAs for keeping a community of talented, motivated people alive. You all rock!