The Solo Dev QA Stack - A Reusable Bug Triage and Release Notes Workflow That Scales

When you are the programmer, designer, and first-line support, bugs do not arrive as tidy tickets. They arrive as Discord pings, email subject lines, and notes app bullets you wrote at 1 AM. Without a single system, you will fix the loudest problem, forget the silent crash, and ship a build whose version string nobody can trace—including you.

This article documents a repeatable stack we keep using on small projects. It is not enterprise ITIL. It is the minimum structure that still works when you add one part-time tester or your first Steam demo deadline.

If you want engine-specific drills, pair this with Lesson 14 - QA Pass and Release Prep for a Godot-shaped pass, and skim Unity 6 Addressables release workflow when content and builds need to stay in sync.

Why solo QA collapses without a system

Solo QA fails for three predictable reasons.

1. Fragmented capture — the same bug exists in a chat log, a TODO comment, and your head. Two get fixed, one ships.
2. Vague severity — everything feels urgent because it is your game.
3. Mystery builds — you upload game_final.zip, then game_final2.zip, and testers report against the wrong binary.

A stack fixes those by forcing one backlog, one rubric, and one naming scheme before you optimize anything else.

One backlog, one truth

Pick one place where every bug lives. For most indies that is GitHub Issues, GitLab, Linear, or Notion with a dedicated database. The tool matters less than the rule—if it is not in the backlog, it does not exist.

Minimum fields per item:

• Title that states the failure in plain language (not “weird camera”).
• Environment (OS, GPU if relevant, windowed or fullscreen, input device).
• Build ID (see below).
• Repro (copy-paste block, see next section).
• Severity (P0–P3 or your own four-step scale).

When someone DMs you a bug, your reply is always the same polite script: “Thanks—please drop this into the tracker with the repro template so I can queue it.” That sounds cold; it saves your sanity.

Severity that maps to ship decisions

Use four levels and write them on a wiki page you link from every issue template.

• P0 - Ship blocker — crash, data loss, progression hard-stop, or storefront policy risk.
• P1 - Major — serious breakage with a workaround, or frequent crash under common hardware.
• P2 - Normal — incorrect behavior that players notice but can finish the demo.
• P3 - Polish — visual glitches, typo-level copy, nice-to-have UX.

Your weekly triage is a 20-minute pass where you only ask two questions: “Is the severity label still right?” and “Is anything P0 hiding inside a P2 title?”

This pairs cleanly with release discipline elsewhere on the site—for example save migration work belongs in P0 territory the moment old files can corrupt.

The repro block you will thank yourself for

Paste this into your issue template and never negotiate it away.

Steps:
1.
2.
3.

Expected:
Actual:

Build:
Platform:
Save file attached (y/n):

Saves matter for RPGs, roguelites, and anything with persistence. If you skip them, you will chase ghosts. If attaching saves feels heavy, ask for export steps instead.

Builds that are impossible to misread

Adopt a build string that encodes date and short hash or incrementing build number from CI. Examples:

• 0.4.2-20260404-a1b2c3d
• demo-steamnext-14 (increment the trailing number every upload)

Put the string in the main menu, in the crash log header, and in your release notes. Testers cannot help you if they cannot prove what they ran.

If you batch Addressables or Godot export presets, align naming with your content pipeline checklist so “wrong PCK” bugs do not masquerade as gameplay bugs.

Release notes as a contract with players

Treat player-facing notes and internal changelog as siblings, not duplicates.

• Player notes — short, outcome-focused, no jargon. Group by “Fixed / Changed / Known issues.”
• Internal notes — PR links, systems touched, risk flags for the next tester pass.

Always ship known issues when you have P1 or risky P2 items. Players forgive honesty faster than surprise crashes. For a bookmark list of checklists and templates from the community, see our build validation resource roundup.

Weekly rhythm that scales from one person to a contractor

Monday — sweep inbox, re-label severity, close duplicates.
Mid-week — two focused test sessions against a written matrix (resolution × input × one story path).
Pre-release — freeze features early enough for a smoke pass on the exact upload candidate.

When you bring in help, hand them the matrix, the build ID, and the P0 list only. Everything else is noise until P0 is empty.

FAQ

Do I need a full test plan document?
Start with a one-page matrix. Expand when players report combinatorial bugs (language × fullscreen × ultrawide).

What if I only have thirty minutes?
Run one vertical slice end-to-end on the lowest-spec machine you own. Half of P0 issues show up there.

Should automated tests replace this?
Automation catches regressions; it does not replace feel and readability passes. Use both.

How do I handle “maybe someday” ideas?
Keep a separate ideas list. Bugs and tasks should be shippable-scope only, or your triage queue becomes a graveyard of feature creep.

Takeaways

• One backlog stops duplicate fixes and lost reports.
• Four severity levels tied to ship decisions beat gut feel.
• Repro templates with build IDs turn chats into actionable work.
• Release notes plus known issues protect trust when you are still learning your bug surface.

You can layer fancier tooling later. Until then, this stack is enough to ship, iterate, and onboard the first human who is not you—without losing the plot.