Compare
RFC123 vs. Notion
Notion is a flexible documentation system that rewards teams who go all-in. Pages, databases, internal links, embeds – it can hold an entire company’s knowledge. RFC123 isn’t trying to be that. It’s trying to be the place engineering decisions are proposed, argued, and recorded next to the code.
Where Notion is better
- Structured databases. Status, owner, deadline, tags – with sort, filter, kanban, and calendar views. RFC123 has none of this beyond the GitHub labels on the underlying PR.
- Internal linking across docs. RFCs that reference project pages, OKRs, customer notes – all in the same graph. RFC123 RFCs link by URL, which is enough, but not connected.
- Live embeds and interactive blocks. Figma frames update in place, Loom videos play inline, toggle and callout blocks shape the reading. RFC123 Markdown does more than people expect (Mermaid diagrams, tables, code, images), but no live third-party embeds and no interactive blocks.
- Cross-functional reach. PMs, designers, leadership, and support are already in Notion. RFC123 needs them to have a GitHub account.
- Mobile and full-text search. Notion’s mobile editing and search across the workspace are mature. RFC123 searches RFC titles and PR descriptions, but not yet inside the Markdown body itself.
- Templates with structured properties. Notion templates carry typed fields. RFC123 templates are Markdown files in your repo – they can’t enforce, say, “every RFC has an owner and a status”.
Where RFC123 is better
- Git-backed history. RFCs change shape between drafts; RFC123 records that as a commit chain with authors, timestamps, and diffs. Notion has a page history slider, but it’s a single timeline – not a structured record an engineer can audit.
- Lives with the code. Same repo as the implementation. Permissions follow the repo, not a separately managed workspace that has to be kept in sync.
- Line-anchored comments in reading view.Comments attach to specific lines of the rendered prose, aligned in a margin sidebar. Notion comments are block-level and inline – good, but not the way most engineers read RFCs.
- A review queue, optionally in Slack. A single feed of RFCs awaiting your review across all your repos. Notion has mentions and an inbox – not “what do I owe a review on”.
- Skills, not just MCP access. Notion has an MCP server too – most serious tools do now. What RFC123 adds on top are opinionated, RFC-aware skills: pressure-test a proposal, compare it to the codebase, synthesize discussion, extract action items, suggest reviewers. Plus a read-only MCP contract so the agent can’t post on your behalf.
- No lock-in. Markdown PRs in your repo – git is the source of truth, not a SaaS workspace.
Side-by-side
| Feature | Notion | RFC123 |
|---|---|---|
| Versioning prose | Page history slider | Real git history: commits, authors, diffs, merge |
| Structured properties (status, owner, deadline) | Yes (databases) | GitHub labels only |
| Internal links across docs | Native graph | URL-based |
| Rich embeds (Figma, Loom, etc.) | Yes | Markdown only |
| Comment anchoring | Block-level, inline | Line-level, margin sidebar on rendered Markdown |
| Lives with code | No | Yes – same repo, same auth |
| Access control | Workspace + per-page | GitHub repo permissions |
| Cross-doc review queue | Mentions + inbox | Per-user queue with optional Slack briefing |
| Full-text search | Yes | Titles and PR descriptions; Markdown body search not yet |
| Agent / MCP access | Yes – write-capable | Yes – read-only by design, with RFC-specific skills |
| Non-engineer access | Excellent | Limited – requires a GitHub account |
| Mobile | Strong | Limited |
| Lock-in | Notion workspace; export available | None – RFCs are PRs in your repo |
So which one should you pick?
Pick Notion if
- Your RFCs sit inside a larger product wiki that crosses functions.
- You want structured properties (status, owner, dates) and database views.
- Embedded designs, recordings, or calendar context matter to the doc.
Pick RFC123 if
- RFCs are an engineering artifact and you want them next to the code.
- You want a real git history of how the proposal evolved – commits, authors, diffs, a merge moment.
- You want agents to participate in discussion without write access.