GitHub Projects vs an issue tracker: when free and adjacent stops being enough

Someone on the team has suggested moving the backlog to a proper issue tracker. The board has got noisy, or a designer cannot see anything, or the Status column has been wrong for a fortnight. For most small teams asking GitHub Projects vs issue tracker, the honest answer is stay where you are.

We build a tracker. That should make you read the rest sceptically, and it does not change the arithmetic below.

The case for staying is stronger than most vendors admit

Money first. GitHub's pricing page lists Free at $0 with "Unlimited public/private repositories" and "Issues & Projects" among its line items (github.com/pricing). Team is presented as "$4 USD per user/month" "for the first 12 months", with an asterisk; the page does not print the standing rate, so we will not either. Nothing paid beats $0 for issues on private repositories.

Then adjacency, the argument people actually make. On a Hacker News thread from February 2022 titled "My team can't move off of using GitHub for project management" (news.ycombinator.com), a commenter puts it about as bluntly as it can be put: "being able to do everything from Github is a huge advantage, not a disadvantage", and "Everyone already has a Github account." Every tool you add is a second place to look and a second thing that drifts.

Projects is also not a toy. GitHub describes it as "an adaptable table, board, and roadmap that integrates with your issues and pull requests", with up to 50 fields per project (docs.github.com) and a ceiling of "a maximum of 50,000 items" (docs.github.com). "You can use the GraphQL API to automate your projects" (docs.github.com), and Actions sit on top of that. A small team will not run out of it.

What we have to say about ourselves in the same breath: Kevta has no importer and no export. Its Import & export screen lists Jira, GitHub Issues, Trello and CSV, then says on its own face that "Importing and exporting aren't available yet". There is no public REST API either. If you have a live backlog in Projects, moving it means retyping it, and once it is here you have no clean way to take it out. That is a real reason to stay put, and it is ours, not GitHub's.

For an all-engineer team working out of one repository everyone can already read, GitHub Projects is the correct answer. Not the cheap answer. The correct one.

The structural fact that decides it

The threshold people expect is a ticket count. It isn't. It is a property of the data model, and you can check it this afternoon.

A GitHub issue's state is binary. The REST API documents two values, open and closed, plus a state_reason of completed, reopened, not_planned or duplicate (docs.github.com). Anything richer lives in a Status field on the project, layered on top.

Now look at what maintains that field. GitHub's built-in automations enable two workflows when a project initialises: when issues or pull requests in your project are closed, "their status is set to Done", and when pull requests are merged, "their status is set to Done" (docs.github.com). The same page describes setting the status to Todo when an item is added.

Arrival and departure, then. The middle is typed by a human, every time, and the middle is the only part anyone asks about. GitHub's own community forum carries a discussion titled "Github Projects workflows - Move issue to In Progress on attaching PR", whose author writes that "There is no automatic moving (workflow) which can move Issue from In Progress to In Review once we ask for review within PR" (github.com/orgs/community). Posted in October 2023, it was auto-closed for dormancy and never answered. A second, posted 19 May 2025, asks the same for draft and ready-for-review (github.com/orgs/community); it has no staff reply either.

So the sharper threshold. To Do and Done are facts about the work. In Review is a fact about a person: someone has stopped and someone else has not started. GitHub knows the exact moment that became true, because a pull request opened. It just does not write it anywhere your board reads. If you never need a state meaning one human is waiting on another, Projects is complete.

Three conditions worth checking

Someone must read the work but should not read the repository

The role that lets a person see issues is a repository role. Read is "Recommended for non-code contributors who want to view or discuss your project" (docs.github.com), and it carries the ability to pull the repository. There is no issues-only tier below it.

Projects inherits that rule: "To view an item on the project, someone must have the required permissions for the repository that the item belongs to. Only people with access to a private repository will be able to view project items from that private repository" (docs.github.com).

Note what the problem is not. It is not money — Free carries private repositories at $0. It is that letting your support lead file bugs means handing them the source, so most teams quietly decide not to and relay bugs by hand.

Work that is not a repository issue

Draft issues go further than people expect: "Draft issues can have a title, text body, assignees, and any custom fields from your project." The catch is one sentence later — "In order to populate the repository, labels, or milestones for a draft issue, you must first convert the draft issue to an issue" (docs.github.com).

So the moment work needs a label, a milestone or a reference from a commit, it becomes a real issue and picks a repository. Fine for code. Odd for renewing a certificate or answering a security questionnaire.

State that has to be true across repositories

A project can span repositories, but by the rule above, two people opening the same cross-repo project see different subsets of it. The backlog stops being one artefact and becomes a per-viewer render of one. On one repo this never comes up. On four, with a contractor on one of them, it comes up weekly.

GitHub Projects vs an issue tracker, side by side

Kevta on the right, since it is the column we can describe from source.

What we built on the assumption that GitHub stays

Kevta is not an alternative to GitHub. It assumes GitHub holds the code and never tries to be a second place to review it.

An issue hands you its own branch name — feature/MS-42-refactor-router, the prefix set per board and the title slug capped at 50 characters. When a pull request appears, Kevta scans the branch ref, the pull request title and its body — and, on a push, the commit messages — for the board key followed by alphanumerics, so MS-42 is found wherever it sits and the -refactor-router tail is ignored. Three match strategies exist if you want it narrower. No magic word, no linking step, which matters because linking a pull request to an issue is a step people forget.

Then the states. A new board seeds eight rules and five ship on: a branch push moves the issue to In Progress, but only if it is currently To Do; a pull request opened or marked ready moves it to In Review; an approving review moves it to Ready for QA; a merge moves it to Done. The three that ship off are all reverse transitions — back to draft, changes requested, closed unmerged — because a rule that drags finished work backwards is contentious enough that you should turn it on deliberately. That reasoning is its own post; board configuration is documented at /docs/boards.

Two limits, plainly. This only covers work with code attached, and plenty has none. And it only works if people use the branch names, which is a habit rather than a guarantee.

Which one fits you

Stay on GitHub Projects if everyone who needs the board is already in the repository, you work in one repo or a few the same people can all read, you are content maintaining Status by hand or with an Action, and you have a backlog in there already — because nothing you move to will import it cleanly.

Look at something separate if one of the three conditions is true today: people who must file and read work but should not have the source, work that is not a repository issue, or state that has to look the same to everyone across several repositories. One condition is a nuisance. Two is a decision.

Either way, keep GitHub. The failure mode worth avoiding is a tracker that wants to be your code host's rival, leaving you to reconcile two records of one pull request. The job is to hold the states GitHub does not model and read the events it already emits.

If that is the shape of your problem, Kevta is in beta and there is a waitlist on the home page — an early invite, a founding-member price at launch, and a direct line to shape what we build next.

Disclosure

We make the tool in the right-hand column, so treat the comparison as interested. Every GitHub claim above links to GitHub's own docs or pricing page, read on 3 August 2026. Check them rather than us.

Kevta's Free plan is $0: 2 workspaces, 5 boards each and 10 members per workspace. Pro is $10 per month per workspace, not per person, and raises those to 10 workspaces, 10 boards and 50 members. Fifty is a real ceiling, not a figure of speech. Current numbers live on the pricing page, which wins if this post has gone stale.