How should I balance sprint tasks with bugs?

Since I am the lead Android engineer, the bugs/crashes are reported to me to fix. Solving these takes time because sometimes I am not the one who worked on it. This leads to my current tasks getting deprioritized.

I would say that It's good, even preferable, to reassign the bug to the person who worked on it because they'll probably have the most context on it, so they'll be able to fix it faster.

At the end of the day, you need to prioritize. I'm a perfectionist, so I try to fix every bug. Unfortunately, that is simply not possible, especially for Android and its extremely fragmented nature.

Fixing a bug as soon as it comes in is ideal but only if it's worth it. In terms of whether it's worth it, that's a tricky calculation but what I will say is that since you work in an early-stage startup, ROI will be much better working on new flashy features instead of trying to patch up every single issue. In terms of whether an issue is worth fixing, ask yourself the following questions:

1. How many users does it affect? (breadth)
2. How severe is the issue when it happens? (depth) Is it a slight inconvenience (e.g. a user needs to click a button an extra time) or a major violation of the user experience (e.g. a user is billed twice on accident)?

If possible, strive to figure out the impact, similar to feature work. Let's say you have a bug where your Google Pay integration can't take American Express cards. Figure out what percentage of users fall into that specific flow and what their average order size is. From there, you can roughly deduce revenue unlock by fixing the bug.

I recommend going over the lessons in my productivity course about prioritization: https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/the-productivity-giant-you-are-missing/

I would say that It's good, even preferable, to reassign the bug to the person who worked on it because they'll probably have the most context on it, so they'll be able to fix it faster.

I agree with Charlie here - In a startup, it's just best to do the naive model where people fix stuff for the areas they've worked on.

Zooming out, if you're feeling swamped with random bugs and are being forced to work on them, talk to your manager. Talk about how it's affecting your roadmap work and the opportunity cost of being distracted with bugs.