Quick answer: Give each game its own project, so it has its own API key, crash-free rate, report widget, public pages and integrations, and look across them from one place. In Bugnet, the Bugs page's All filter lists every game's bugs together, and one invitation gives a teammate access to every project in the account. The free plan covers one game, Studio covers five, and Studio Plus has no project limit.

The first game is easy: one tracker, one board, one Discord channel. The second game is where it breaks. A crash from the old game lands in the new game's sprint, the live game's players get ignored during the new launch, and nobody can answer “how healthy is each game?” Here is a structure that scales.

One project per game, not one big pile

Separate projects keep the things that must not mix apart:

Use separate projects for separate SKUs too when they are effectively different products, such as a mobile port built from a different branch. Keep one project for a game shipped on several stores from the same code, and let the platform field tell them apart.

One view across every game

Separation is only half the job; a producer or solo developer also needs one place to see everything. On Bugnet's Bugs page, the project selector has an All option that lists bugs from every project together, with the same status filter, search, sort and labels you use within a game. Save that view, for example every game's open bugs sorted by priority, and it becomes your daily check.

One team, every game

In Bugnet, projects belong to an account, and inviting someone to the account gives them every project in it, with permissions set once for the account rather than per game. A QA lead hired for the new game can see the live game's crashes on day one, and removing someone removes them everywhere. Seats and report limits are shared across the account, so adding a game does not add per-project fees.

Route alerts and issues per game

A weekly rhythm for a multi-game studio

  1. Daily: check the All view, sorted by priority, for new critical and high bugs.
  2. Weekly: review each live game's crash-free rate and top crashes, then plan fixes per game.
  3. Per release: compare the new version with the previous one before rolling out more widely.
  4. Shared code: when one bug lives in an engine or library several games share, fix it once and note the fix in each game's bug so each can close it after its next patch.

What it costs

Bugnet's free plan covers one project with up to 100 reports. Studio ($19 a month) covers up to five projects, 10,000 reports and 20 team members, and Studio Plus ($79 a month) removes the project, report and member limits. Create a free project for your first game and add the others when you upgrade.

Frequently asked questions

Should each game have its own bug tracker project?

Yes. A project per game keeps crash-free rates, versions, reviews, public pages and API keys separate, and you can still see every game's bugs together in one view.

Can I see bugs from all my games in one list?

Yes. In Bugnet, the Bugs page's project selector has an All option that lists every project's bugs together, with the usual filters, search and sorting.

Do I have to invite my team to each game separately?

No. In Bugnet, inviting someone to your account gives them access to every project in it, and removing them removes them from all projects.

How many games can I track on Bugnet's plans?

One on the free plan, up to five on Studio, and unlimited on Studio Plus. Report limits and team seats are shared across the account.

Should a console or mobile port be a separate project?

If it is built from a separate branch and versioned separately, yes. If it ships the same code and version numbers on several stores, keep one project and use the platform field.

Separate where the data means different things. Combine where people need to see everything at once.