29 Bugs, One Week: How I Sequenced the Fix Queue
TL;DR
- Situation: 29 tracked bugs across two repos, 7-day release window, one person shipping.
- My decision: Sequenced by testability first, severity second — "highest severity first" strands you when the top bug takes 2 days to reproduce.
- Outcome: All 29 shipped in v2.0.0. Zero crashes on TestFlight build 2. IPA delivered to Apple within a week of first fix.
The problem
Voice v2 had accumulated 29 tracked bugs plus dozens of untracked ones. Some blocked all further testing (auth persistence — every regression path required a working login). Others only surfaced in rare edge cases (a saved-post state leak that needed two accounts and a specific save-order to reproduce). All had to ship in one release.
The constraint
One person, one week, no CI/CD, no QA team. I could either fix "highest severity first" or fix "highest testability first." I picked the second and it changed the pace of the whole release.
What I killed: severity-first prioritization
"Highest severity first" is what every JIRA template tells you to do. It's correct in theory. In practice, when the highest-severity bug takes 2 days to reproduce and 6 hours to fix, you spend day 1 of your week not shipping anything and can't test anything else in parallel.
I killed that ordering and replaced it with three rules.
What I shipped: three-rule sequencing
Rule 1 — Fix testing-blockers first. Any bug that prevents other bugs from being reproduced ships in the first 24 hours. For me that was Bug #1 (auth persistence — the app was logging users out on every close) and Bug #10 (backend rejected the saved-event flow, blocking all saved-content bugs downstream).
Rule 2 — Fix visible-in-30-seconds bugs next. If I can see it by opening the app and tapping once, the smoke test finds it. Shipped wrong timestamps, missing photo renders, wrong 3-dots menu behavior. These are the bugs beta testers report first, so shipping them early gives me a cleaner signal from testers.
Rule 3 — Multi-account bugs go last. They need setup (create User A, log in as User B, share state, log out, log back in as A). That setup breaks constantly during a rewrite window. I ship them at the end when the rest of the app is stable.
What I'd measure
For any release with N bugs, I'd track "bugs fixed before smoke-test was possible" as a percentage of total. If it's below 60%, I sequenced badly — too many bugs shipped without visibility into whether they'd broken anything else. In v2 my number was 79%.
What I'd do differently
I'd fix state-leak bugs (SavedRepository not clearing on logout, setState-after-dispose in GroupSettingsSheet) earlier in the sequence. I put them last because they seemed "edge case," but they were actually blocking an entire class of multi-account test that would have surfaced 3 other bugs sooner. Next release, state-leak bugs go in Rule 1.
Related: This case study is expanded from my Medium article of the same name . Both are public and up-to-date.