How We Triage Bugs as a Tiny Indie Team: A Devlog Postmortem

It was 11:47 PM in our Manchester flat-turned-studio, and the tea had gone cold again. We were staring at a browser game prototype that had decided, with spectacular timing, to hard-crash Google Chrome every single time a player touched the inventory icon. A playtest with eight fellow devs was scheduled for nine the next morning. One of us suggested cancelling. Another was already knee-deep in the console, muttering about a misbehaving WebGL call. That night, we didn’t just fix a bug—we realised our entire ‘fix-as-we-go’ philosophy was a house of cards. This devlog postmortem unpacks how that moment forced us to build a bug triage system that actually works for a tiny indie team, and what the data from our last three prototype cycles revealed about where our time really vanishes.

The Breaking Point: Why We Needed a System

Before that night, our approach to bugs was proudly organic. Someone spotted a glitch, shouted across the room, and whoever felt least buried in their current task would dive in. For a solo hobby project, that’s fine. For a team of three juggling a browser game prototype, a UK Games Fund grant application, and the creeping anxiety of Manchester’s rising cost of living, it was a disaster. The breaking point wasn’t just the crash itself—it was the two hours of duplicated effort that followed, because we hadn’t realised two of us were trying to patch the same corrupted save-state logic from different angles.

The Playtest That Almost Wasn’t

We’d booked that playtest session weeks in advance, carving out time during a lull between the chaos of EGX London 2024 and our next milestone deadline. The prototype was a narrative-driven browser game built in Phaser, and we’d been so focused on getting the dialogue trees to feel right that we’d neglected systematic testing. When the crash surfaced, our immediate reaction was panic-fixing—a frantic, adrenaline-fuelled scramble that introduced two smaller regressions we only caught because a playtester’s laptop was running an older version of Mozilla Firefox that handled the canvas element differently. The session happened, barely, but the feedback we received was coloured by instability we should have caught days earlier.

Identifying the Real Cost of Context Switching

What stung most wasn’t the late night—it was the creative hangover. The day after that playtest, none of us wrote a single line of meaningful code. We were fried. Context switching, we learned, isn’t just a productivity buzzword; it’s the silent killer of indie game devlog momentum. Every unplanned bug fix yanks a developer out of their creative flow, and for a tiny team, that cognitive reset can eat an entire morning. We started tracking it informally and found that a single unplanned interruption cost us, on average, forty-five minutes of productive design work. Multiply that by three people and a dozen surprise bugs per sprint, and the maths was grim.

Defining Severity When Everything Feels Urgent

When you’re sleep-deprived and staring at a red error log, every bug feels like a five-alarm fire. We needed a shared language to cut through the noise. Rather than adopting a rigid corporate scale, we built a subjective one tailored to the realities of a browser game prototype where polish isn’t always the priority. Our scale now runs from ‘Crasher’ to ‘Cosmetic’, with a special category we call ‘Comment Section Fuel’—because if a player on itch.io will publicly eviscerate us for it, it jumps the queue.

Crashers vs. Softlocks in the Browser

We draw a hard line between a crasher that dumps the player back to the desktop—or, in our case, freezes the browser tab entirely—and a softlock that traps the character behind a rock but leaves the game running. Crashers are instant P0 tickets, no questions asked. Softlocks get a severity rating based on how close they sit to the critical path. During our last prototype, a softlock in the tutorial level was treated as a crasher because it blocked first-time player retention; the same softlock in a hidden easter-egg room was marked P3 and sat in the backlog for two weeks. Browser-specific crashers, like the one that only manifested in Chrome’s V8 engine after a specific garbage-collection cycle, get their own sub-label so we can test in isolation.

The ‘Itch.io Comments Section’ Priority Factor

We have a rule: if a bug would generate more than three comments calling it out on our itch.io page, it gets bumped one severity level. It sounds flippant, but it’s grounded in reality. The indie game devlog community is wonderfully vocal, and early prototype players are often more forgiving of missing content than they are of a UI element that overlaps unreadably on a 1366×768 laptop screen. That specific bug—a CSS flexbox issue in our dialogue panel—sat at P4 until we imagined the comments. It was fixed by lunchtime.

The 10-Minute Stand-Up Triage Ritual

Every morning at 9:30, mugs in hand, we gather around a single monitor and triage. The entire ritual is capped at ten minutes. If a discussion threatens to spiral, we table it and the most senior dev on the feature makes the call. The goal isn’t consensus; it’s clarity. By 9:40, every new bug report from the previous day has a severity label, an owner, and a rough sprint placement. This tiny investment has saved us more hours than we can count.

Tools We Actually Use (And the Ones We Ditched)

We started with Jira because it felt ‘professional.’ We lasted three weeks. For a team our size, the configuration overhead was absurd. We switched to a shared Trello board with four columns—’Reported,’ ‘Triaged,’ ‘In Progress,’ ‘Verified’—and a handful of labels for severity and browser type. GitHub Projects now handles our code-linked tickets, but Trello remains our visual triage dashboard. The simplicity is the point. We also experimented with a Discord bot that logged bugs from chat messages, but it created too much noise. Now, bugs live in Trello or they don’t exist.

Assigning the ‘Fixer’ vs. the ‘Verifier’

One rule we stole from a talk at EGX London 2024: the person who fixes a bug is never the person who verifies it. On a team of three, that means verification often falls to the person whose domain is furthest from the fix—our narrative designer verifies engine patches, our programmer verifies UI fixes. It’s not about distrust; it’s about fresh eyes. We’ve caught so many ‘fixed’ bugs that still failed on Firefox because the fixer only tested on Chrome. The verifier’s job is to be the grumpy player who does everything wrong.

The Art of the ‘Won’t Fix’ for a Prototype

Closing a bug without fixing it feels like failure. But for a prototype, knowing what not to fix is a survival skill. Our last browser game prototype had a crafting system that generated seventeen bug tickets. We closed fifteen of them as ‘Won’t Fix’ after a brutally honest postmortem revealed the crafting loop wasn’t fun enough to justify the stability cost. That decision shaved two weeks off our timeline and let us polish the dialogue system that players actually cared about.

Killing Your Darlings to Save the Build

There’s a particular pain in cutting a feature you’ve already prototyped and shown in a devlog update. Our crafting system had its own devlog post, complete with GIFs and enthusiastic comments. Killing it felt like a public retreat. But the Interactive Entertainment Law considerations around our UK Video Games Tax Relief claim meant we needed a stable, playable vertical slice for our evidence package—and no amount of crafting charm would matter if the build crashed during the assessor’s review. We framed the cut not as a failure but as a strategic descoping, and the devlog post explaining it became one of our most-read updates.

How We Document ‘Never-Fix’ Decisions for the Future

Every ‘Won’t Fix’ ticket gets a short postmortem note explaining why. Not just ‘out of scope,’ but the specific reasoning: ‘Crafting UI conflicts with our dialogue-layer z-indexing; not worth refactoring for a prototype.’ These notes are gold when we revisit the concept for a full release or a new prototype. We also tag them with the prototype version number so we can filter them later. During our UK Games Fund grant application, we actually referenced these documented decisions as evidence of our iterative design process—turning what felt like a graveyard of dead features into a portfolio of disciplined scoping.

Postmortem: What Our Triage Data Tells Us

After three full prototype cycles, we crunched the numbers. Across 214 logged bugs, a clear pattern emerged. Browser compatibility issues accounted for 38% of all tickets. UI bugs—misaligned elements, unclickable buttons, font rendering quirks—made up 31%. Physics and gameplay logic bugs sat at 22%, with the remaining 9% spread across audio, save systems, and miscellaneous gremlins. Those percentages shifted our entire pre-production approach.

Common Browser Compatibility Culprits

Google Chrome and Mozilla Firefox remain our primary testing targets, and they disagree on more things than we ever expected. Firefox’s handling of the Web Audio API consistently produced crackling in our ambient sound layers that Chrome played cleanly. Chrome’s aggressive caching sometimes served stale JavaScript bundles after a hot-reload, leading to ‘bugs’ that didn’t actually exist in the current build. We now maintain a living document of known browser quirks, and every new team member reads it during onboarding. The biggest culprit across all three cycles? CSS Grid behaviour inside iframe embeds on itch.io—a nightmare we’ve learned to test first, not last.

Turning Bug Trends into a Pre-Production Checklist

That 38% browser compatibility figure was a wake-up call. We now run a pre-production checklist before writing a single line of game logic: test the empty canvas on Chrome and Firefox, verify audio context initialisation, check the viewport scaling at three resolutions, and confirm that the itch.io embed sandbox doesn’t break our input handling. It takes thirty minutes and has eliminated an entire category of late-stage panic. The checklist is a living document, updated after every postmortem, and it’s become the most boring but valuable asset in our toolkit.

Balancing Triage with Creative Momentum

Rigid triage can sterilise a project. The spark that makes an indie game devlog worth following often comes from unplanned experimentation—the kind that generates messy, low-severity bugs by its very nature. We’ve learned that the goal isn’t to eliminate chaos but to contain it, so it doesn’t poison the parts of the build that need to be stable.

Scheduled ‘Chaos Hours’ vs. Structured Sprints

Every Friday afternoon, our sprint rules relax. Chaos Hours are a two-hour window where anyone can prototype anything, no tickets required, and bugs discovered during that time don’t enter the triage queue unless they affect the main branch. We branch off, experiment wildly, and either merge the results into a feature branch or discard them entirely. This rhythm—four days of structured sprint, one afternoon of creative freedom—has kept morale high even as Manchester’s indie scene grapples with the rising cost of living and the pressure to monetise earlier than ever. Some of our best devlog content has come from Chaos Hour experiments that were never meant to ship.

Protecting the Devlog Narrative from Technical Noise

Our devlog isn’t a changelog. Readers don’t need to know about every CSS fix or WebGL edge case. We protect the narrative by filtering what reaches the public: bug fixes become devlog content only when they teach something universal or reveal something about our process. This postmortem is an example—the crafting system cut became a story about scoping discipline, not a list of closed tickets. The triage system itself, the behind-the-scenes plumbing, stays invisible so the devlog can focus on design, art, and the human experience of making games.

Conclusion

Bug triage, done right, is a mental health tool disguised as a workflow. It shields us from the crushing feeling that the build is perpetually broken and we’re perpetually behind. It gives us permission to close tickets, to say ‘not now,’ to protect the hours when we’re actually making something new. For a tiny indie team documenting their journey through devlogs, that protection is everything. The chaos of that late-night crash in our Manchester flat taught us that passion alone can’t ship a browser game—but a lightweight, honest triage process can keep that passion burning long enough to cross the finish line.

FAQ

How do you handle bug triage when the whole team is working remotely?

We’ve experimented with remote stand-ups during periods when one of us was travelling, and our ten-minute ritual translates surprisingly well to a quick video call with screen sharing. The key is keeping the Trello board visible to everyone and resisting the urge to extend the meeting. Async triage via Slack threads failed for us—too much back-and-forth, not enough decisions.

What’s the most common browser-specific bug you encounter in prototypes?

Without question, it’s CSS Grid and flexbox behaviour inside itch.io’s iframe embed. Firefox and Chrome handle the constrained viewport differently, and elements that look perfect in a local build can overlap or vanish entirely once embedded. We now test inside an iframe from day one of UI development.

Do you use automated testing for your browser game prototypes?

Not yet, and that’s a deliberate choice. Our prototypes shift too rapidly for automated tests to be cost-effective. We rely on manual testing checklists and our verifier system instead. For our next project, which has a longer lifespan, we’re exploring Playwright for basic smoke tests across Chrome and Firefox.

How did your triage process affect your UK Games Fund grant application?

Surprisingly positively. The documented ‘Won’t Fix’ decisions and bug trend analysis demonstrated a mature, iterative development approach. The assessors specifically noted our postmortem data as evidence that we understood our technical risks—something that strengthened the application considerably.

What’s the one tool you’d recommend for a tiny indie team starting triage?

A simple Trello board with no more than four columns and a handful of labels. Resist the urge to over-configure. The value isn’t in the tool; it’s in the daily ritual of looking at the queue together and making decisions quickly. Fancy automation can come later, if at all.