Compare
RFC123 vs. Google Docs
Google Docs is the documentation system most teams already know. It starts fast, welcomes non-engineers, and has the best prose-editing experience of any tool on the web. 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 Google Docs is better
- Real-time co-editing. Multiple cursors in the same paragraph. RFC123 doesn’t do this – you write locally and commit when you’re ready.
- Suggestion mode. Track-changes for prose is a genuinely better editing model than diffs for prose. RFC123 only has comments – it doesn’t propose edits on text.
- Anyone with an email can read. No GitHub account required. PMs, designers, leadership, and legal can participate without onboarding to a new tool.
- Live embeds and freeform layout. Live Google Sheets, hand-drawn Drawings, images placed anywhere with text wrap. RFC123 Markdown does more than people expect (Mermaid diagrams, tables, code, images) but no live third-party embeds and no freeform placement.
- Mobile and offline parity. Docs is mature on phones and tablets, and works offline. RFC123 is desktop-first and shows it on small screens.
Where RFC123 is better
- Git-backed history. Every RFC carries a real commit chain – authors, timestamps, diffs, a merge moment. Docs has a revision slider; git is what your engineering team already trusts as the durable record.
- Lives next to the code. Same auth, same permissions, same repo as the implementation. No drift between “who’s in the workspace” and “who has access to the codebase”.
- Line-anchored comments that stick. Threads attach to lines in the rendered Markdown – they don’t drift if the text above them reflows.
- A review queue across all your repos. One list of RFCs awaiting your (or your GitHub team’s) review, optionally delivered as a Slack DM in your timezone.
- Agent-native. Connect Claude, ChatGPT, or any agent over MCP for read-only access – plus pre-built skills for pressure-testing, comparing to the codebase, and synthesizing discussion.
- No lock-in. Walk away tomorrow; every RFC is still a Markdown PR in your repo.
Side-by-side
| Feature | Google Docs | RFC123 |
|---|---|---|
| Real-time co-editing | Yes | No – write locally, commit when ready |
| Suggestion / track-changes | Yes | No – comments only |
| Versioning model | Revision timeline | Real git history: commits, authors, diffs, merge |
| Line-anchored comments | Approximate (can drift with edits) | Yes, on rendered Markdown lines |
| Lives with your code | No | Yes – same repo, same auth |
| Access control | Google share / domain | GitHub repo permissions |
| Cross-doc review queue | No | Yes – Slack briefing, opt-in, per-user timezone |
| Full-text search | Yes | Search RFC titles and PR descriptions; Markdown body search not yet |
| Agent / MCP access | No (manual copy-paste) | Yes – read-only by design, with skills |
| Non-engineer access | Excellent | Limited – requires a GitHub account |
| Mobile editing | Strong | Limited |
| Lock-in | Google Workspace | None – RFCs are PRs in your repo |
So which one should you pick?
Pick Google Docs if
- Your reviewers include people without GitHub accounts.
- You need multiple cursors in the same paragraph as you draft.
- The doc is cross-functional or one-off – not an engineering decision you’ll need to find in three years.
Pick RFC123 if
- Your RFCs are engineering decisions, and you want them next to the code.
- You want a single review queue across every repo you can access.
- You want agents in the loop without write access.