I let a bug go live. Twenty minutes later, we had to do a hotfix and go through another round of testing, submit our app to the stores and release it again - all because of me.
I’m not going to lie.
I was really hard on myself. But guess who wasn’t? My team. Yes, it was my fault. Yes, there were things I should have done differently, and I take full accountability for that.
But there was no blame.
The bug itself wasn’t catastrophic, and it wouldn’t have caused real harm to Solflare or our 4 million users. But it did create some extra work – work that none of us really needed, especially knowing how full everyone’s plates already are.
I’m confident I won’t make the same mistake again anytime soon, not because I’m more careful out of fear but because I truly own what went wrong. But what does that mean?
Owning the failure meant not brushing it off, not looking for excuses, and not shifting the responsibility elsewhere. It meant taking the time to understand what actually went wrong. The issue itself wasn’t particularly complex, but it revealed a gap in how I approached testing that release. I verified the behavior on the parts of the UI that already existed, and everything worked as expected.
What I didn’t connect at the time was that a new part of the UI was being introduced in the same release. Because of that, I never validated the same behavior there. That small oversight allowed the bug to slip through.
Looking back, the real lesson wasn’t about that specific issue. It was about staying aware of how product changes interact with each other – especially when new pieces are introduced alongside existing functionality.
That experience changed my perspective on quality. Real quality doesn’t come from avoiding mistakes at all costs – it comes from acknowledging them, learning from them and doing better next time.
Ownership truly makes you a better QA
When I first started working as a QA, I had someone who closely followed my tasks, helped prioritize them, and guided me through what needed to be done next. At the time, that meant I didn’t really have to think much about priorities or the broader context – I just focused on completing what was assigned to me.
But when I joined a team where I had more autonomy in how I approached my work, I had to start thinking about my role differently.
After finishing the onboarding process, there came a point where it was time to start working more independently. That’s when I realized I wasn’t entirely sure where to begin. I had to figure out how to organize my work – how to balance writing tests, validating tickets, conducting exploratory testing and how to decide what to prioritize first.
Looking back, that initial uncertainty was a turning point. It forced me to stop working mechanically and start thinking critically about what I was doing and why. I had to learn how to prioritize, how to look at the product as a whole, and how my work fits into the bigger picture.
Once you let go of the idea that someone needs to babysit you in your day-to-day work – managing your time and telling you exactly what to do – your perspective completely changes. You stop thinking in terms of individual tasks and start owning the entire flow from the implementation to the final product quality. Your focus shifts from simply verifying that something works to understanding how it behaves as part of the bigger picture and how it ultimately affects the user.
There will be moments when it’s tempting to hide behind your job title – to think that something falls outside your responsibilities so it’s not really your problem. But when it comes to product quality, things are rarely that simple. If you notice something that could impact the user experience and you have the ability to help, stepping in matters more than where the responsibility officially sits.
In many teams, quality assurance is treated as a final step in the process – something that happens after the work is done and is owned by a specific person or team. This can unintentionally create a mental boundary: “this isn’t my area” or “QA will catch it later.”
Quality Even Before It Reaches QA
The reality is that product quality is shaped long before anything reaches formal QA. Small decisions around design, wording, edge cases, and assumptions all directly affect the user experience, and they’re often most visible to the people closest to the work.
That’s why this mindset asks for a shift – from seeing quality as a role, to seeing it as a shared responsibility. QA remains crucial, but it works best as a safety net, not the first line of defense. When someone notices a potential issue and has the ability to help, stepping in early is often what makes the biggest difference for the user.
When I notice a user report about an issue I can’t directly fix myself, that doesn’t mean my involvement should stop there. Thinking back to the bug I mentioned at the beginning, this is the mindset I try to apply today. Instead of seeing it only as a mistake, I see it as a reminder to stay involved until the issue is fully understood and reaches the right people to resolve it. Even if I’m not the person who will resolve the problem, I can still investigate the context, try to reproduce the issue, gather as much information as possible, and make sure it reaches the right person. By doing that, I’m not taking over someone else’s work – I’m helping move the issue forward and making it easier to resolve.
What’s More Important Than Finding a Problem To Solve
Ownership and teamwork go hand in hand. Taking responsibility for quality doesn’t mean working in isolation or trying to solve everything on your own. In fact, ownership often shows itself through collaboration. When an issue comes up, being willing to reach out, share context, and work together is just as important as identifying the problem in the first place.
I experienced this exactly while working on the implementation of prediction markets at Solflare. At the time, I didn’t fully understand how prediction markets work in general, let alone in a web3 context. Instead of making assumptions or stepping back, I openly said that I didn’t fully understand how it should work.
We set up a huddle and walked through the main scenarios together – how users interact with the market, what happens in edge cases and where confusion could arise. I asked a lot of questions and made sure I could clearly explain the flow back in my own words. That process helped us make better product decisions and avoid issues early.
It’s important not to fool yourself into thinking you won’t need help – because you do. I need help all the time, especially in areas outside my core expertise. Needing help doesn’t mean you’re losing ownership. If anything, it means you’re still holding the reins.
Being surrounded by people who are better than me in certain areas is an advantage. Asking for help doesn’t take ownership away from me – it strengthens it and ultimately leads to a better product and user experience.
You don’t need permission to care more or to take responsibility for quality. Not waiting to be asked means trusting your instincts, sharing your perspective, and being willing to act when you see an opportunity to make things better. At Solflare, this feels natural because everyone is encouraged to speak up, share feedback and contribute their perspective at any stage of implementation – without hesitation.
Ownership isn’t about crossing something off a list and forgetting it. It’s about staying present – caring about the impact, listening to feedback, and being ready to step in if something isn’t right. Quality doesn’t stop at release, and neither does responsibility.
That also means regularly revisiting features that went live a long time ago – checking how they behave in real use, staying aware of potential issues and helping improve them in any way I can as the product continues to evolve.
Staying Connected To The Product – Without Fear
Being trusted to work this way is what gives me the freedom to do my best work in QA at Solflare. That trust allows me to stay connected to the product without fear, to take responsibility without feeling controlled, and to care deeply without burning out. For me, that’s what ownership truly means: being there not just until something ships, but for everything that comes after – supported by trust, driven by responsibility, and focused on building a better product.
The bug I started this story with still haunts me – but not in a solely negative way. It stays with me as a clear reminder of what I learned from that moment and how much it shaped the way I work.
