Notion for project management: where a hand-built tracker breaks

A Notion tracker usually starts the same way. Someone makes a database called Tasks, adds a Status select, switches it to board view, and by the end of the afternoon the team has a working kanban board next to the specs it was already writing.

Thousands of small teams run on that setup, and the version of this argument that treats them as naive is not worth reading. Notion databases are a genuinely capable tracker. Before taking one apart it is worth being precise about what it does, because most critiques of Notion for project management are out of date by about two years.

Why teams pick Notion for project management

A Notion database is not a spreadsheet with a nicer font. The same rows render as Table, Board, Timeline, Calendar, List, Gallery or Chart, each view keeping its own filters and sorts, and a filter can be saved for everyone or kept to yourself — the help page tells you to Save for everyone only if you want everyone to get it (notion.com/help). That is more view types than most dedicated trackers ship.

Relations connect two databases, work one-way by default or bidirectionally, and can point a database at itself for sub-tasks; rollups then aggregate across the relation — count, sum, earliest date, latest date (notion.com/help). Formulas compute over other properties and across relations, including conditional logic and date arithmetic (notion.com/help). Database automations fire on a page being added, a property being edited, or on a recurring schedule, and can edit a property, add a page to another database, notify someone, or send a webhook — "available on paid plans on all platforms" (notion.com/help).

Two more, and these are the ones people get wrong.

Notion has stable short IDs. The Unique ID property assigns a permanent number to every page — "Unique ID numbers always start at 1 and are assigned to every page, including deleted pages" and "ID numbers will never change" — and with a prefix set you get a working permalink of the form notion.so/TASK-123 (notion.com/help). ENG-412 in a branch name is not something Notion cannot do.

Notion links pull requests. The GitHub connection provides a Pull Requests property that can move a task's status automatically "when the GitHub PR is Opened, Review Requested, Approved, and Merged" (notion.com/help). That is the core of what an engineering team wants from a tracker's Git integration.

So the honest summary is that a Notion database can be an issue tracker, with IDs, PR linkage and automation. The problems are elsewhere, and they are mostly about who assembles it, who owns it afterwards, and what tier it lives on.

Where a Notion tracker breaks

The parts that make it a developer tracker are on the $20 tier. This is the sharpest one. Notion's pricing page lists Free at $0, Plus at $10 per member per month and Business at $20 per member per month, with Enterprise quoted (notion.com/pricing) — the page advertises a saving for yearly billing, so check which period the toggle is showing before you do arithmetic on those numbers. Database automations need a paid plan (notion.com/help). And the GitHub property is higher still: "GitHub connected properties are only available on Business and Enterprise Plans" (notion.com/help). A team of six that wants pull requests to move their board is looking at Business for six members, and per-member pricing has its own gravity that we have written about elsewhere.

Somebody built it, and that somebody now owns it. A dedicated tracker ships with an opinion about what an issue is. A Notion tracker is a schema one person designed on a Tuesday: which properties exist, what the Status options are, how the rollup to the epic database works, which of the four board views is the real one. That design is not documented anywhere except in the database, and the person who holds it in their head is the person everyone asks. It is the Jira administrator problem in a friendlier costume — same recurring tax, no job title, and nothing to hand over when they leave.

Permissions inherit from the page tree. Notion's model is page-shaped: "When you create a subpage inside of a page, that subpage will take on the permissions of its parent page" (notion.com/help). Every row in your tracker is a page, and every one of them can be shared independently of its database. Restricting access per row — letting people edit the tickets they created but not each other's — is a separate feature, and Notion's pricing page puts granular database permissions on Business and Enterprise. This is fine when everyone sees everything. It gets awkward the first time a contractor needs one board and not the roadmap doc two levels up.

The performance advice is to look at less of it. Notion's own optimisation page is candid: "If your database has a ton of pages, it might be slower to load", "The more visible properties your database has, the longer it might take to load", and "Databases that are filtered and sorted on formula and rollup properties may take a bit longer to load". Its suggested fix for large databases is a filter on Created time to hide old rows, and hiding properties you care about less (notion.com/help). The documented ceilings are high — 500 properties and 250,000 rows per database — so this is not about hitting a wall. It is that the remedy for a slow tracker is to stop showing you your work, and that the formula-and-rollup scaffolding you added to make it feel like a tracker is the part that costs you.

Scripting around it is slower than you expect. If you decide to close the gaps yourself, the API allows "an average of three requests per second" per integration and returns a maximum page_size of 100 (developers.notion.com, developers.notion.com). That is enough for a nightly sync and thin for anything interactive.

And then it is an internal product. The tracker accretes: a rollup here, a button there, a second database for epics, four views because three people wanted different defaults. Rollups cannot even chain — Notion's answer to "Can I rollup a rollup?" is "Unfortunately not, as this could create unintended loops" (notion.com/help) — so the workarounds start early. None of it is written down and nobody is assigned to it.

Notion vs Jira for small teams

These get framed as the two options and they are not a pair. Jira is a configurable platform that assumes an administrator; Notion is a flexible document tool that quietly recruits one. The failure mode is the same shape — someone on a small team maintaining structure instead of shipping — arriving by different routes. If the Jira half of that decision is where you are, that is its own comparison. Worth noticing: "we'll build it in Notion" and "we'll configure Jira properly" are both answers to a question most teams of five should answer with a much shorter list — what a five-person team actually needs from issue tracking.

Feature by feature

Notion facts checked against Notion's own documentation on 8 August 2026. Both products ship continuously; the linked pages are the version that counts.

Where Notion genuinely wins

Not a courtesy section. There are teams for whom leaving Notion would be a straightforward mistake.

The specs are already there. The one thing a tracker cannot do is hold the document the work came from. In Notion, the PRD, the meeting notes where the scope changed, the roadmap and the ticket are the same kind of object, in the same search index, linked to each other without an integration. If your team's thinking already lives in Notion, moving the tickets out means every ticket now points at a different tool — and that seam is a real, permanent cost that most comparisons skip. Kevta has no documents at all. It cannot even hold a file attachment.

Flexibility is the feature. A dedicated tracker's opinion is only an advantage when you agree with it. If your work does not decompose into issues — research, content pipelines, client deliverables, a hardware bill of materials — relations and formulas will model it and a tracker will not.

Non-engineers already have it open. The designer, the founder, the support person: they are in Notion daily and they are not going to adopt a second tool for three tickets a month. A board everyone actually looks at beats a better board half the team ignores, and this is the single most common reason a consolidation decision is correct. It is also why adding another app is not a free move — see the cost of one more app.

Writing in it is better. Long issue descriptions, decision records, and anything that wants a heading and a table read better in Notion than in almost any tracker's description field.

Which one fits you

Stay on Notion if your specs and roadmap already live there, your team includes more non-engineers than engineers, or the thing you are tracking is not really issues. The consolidation is worth more than everything above.

Move to something dedicated if you can name the person who maintains the database and it bothers you, if you want pull requests moving your board without paying per member for a Business plan, or if the honest answer to "what is the current state of the work" is that someone has to go and tidy the board first.

Disclosure

We build an issue tracker, so read the above as an argument rather than advice. Kevta is in beta. It has stable issue keys and full history on every issue, board, list, table and calendar views, and GitHub built in — copy a branch name off an issue, and the pull request finds its own issue by key with no linking step, on the free plan as well as the paid one. Free is $0 for 2 workspaces, 5 boards each and 10 members; Pro is $10 a month per workspace, not per person, raising those to 10 workspaces, 10 boards and 50 members. Fifty is a real ceiling. There are no documents, no file attachments, no reporting, no sprints and no importer, which for a team whose work already lives in Notion pages may well be disqualifying.

The part that stands on its own is the diagnostic. Open your Notion tracker and ask who would fix it if the person who built it left. If the answer is nobody, you do not have a tracker — you have an internal product with one maintainer, and that is true whatever tool it is built in. If you would rather that were somebody else's problem, Kevta's beta waitlist is open.