Inside Rezee - why specs live next to the code (Ideate & Design)
The thinking behind Rezee's Ideate & Design layer - a block editor with live presence, RFC templates and numbering, live references, and specs that live next to the code they describe.
Jul 22, 2026 · 3 min read · Kash Gohil
Rezee is one workspace for everything a team ships, organized as five layers on one data model. This post is about the first: Ideate & Design - where specs, RFCs, and product thinking live. The layer exists because of a conviction: the most expensive failures in software happen before any code is written, in documents nobody could find, review, or trust.
Why put a document editor in a development platform?
Because the spec is not paperwork about the work - it's the first artifact of the work. In the standard stack it lives in Notion or Google Docs, disconnected from everything downstream, which is why specs drift into fiction and teams quietly stop writing them. Put the document where the issues, code, and discussion live, and it can stay connected to what it caused - the difference between docs that rot and docs that don't.
What's actually in the layer?
A block-based editor built for engineers. Markdown-first input, slash-menu everything, callouts, tables - and live embeds: reference an issue or a PR and the embed updates itself as the work moves. A spec that shows current reality instead of the day it was written.
Presence, and saves that don't clobber. Open a doc and you see everyone else who has it open, and who is typing. A save carries the version it started from, so one that raced someone else's is refused rather than landing on top of it. Specs are group documents; the editor should assume that.
Docs that nest. A spec lives in a tree beside the runbooks, notes, and appendices around it, numbered per workspace so RFC-008 means one thing to everyone. Structure the team can navigate six months later, rather than a flat pile of pages.
RFC templates. Team-owned templates and automatic numbering: any doc your team keeps re-creating becomes a template with one action. Process without a process document; the shape we recommend in how to write an RFC is there when you start a new one.
Live references. Name an issue, a pull request, or a file in a spec and it resolves every time the doc is read - never a pasted title that went stale. A spec read six months later still shows what actually happened to the work it describes. Where this is going is the closed loop, starting from the top.
How does it connect to the other layers?
The spec sits in the same workspace as everything it describes: it references issues in Plan & Track and PRs in Code & Ship live, chat mentions in Discuss unfurl the doc, and an agent watching pushes drafts the doc update a commit implies. One search covers docs along with everything else.
FAQ
What is Rezee's Ideate & Design layer?
The document layer of the Rezee workspace: a block-based editor for specs, RFCs, and engineering knowledge, with live presence, templates and per-workspace numbering, and references to issues and code that resolve as you read.
Can I use it without adopting RFC process?
Yes - it's a full editor for any document. The RFC machinery (templates, numbering) is there when you want it; plenty of docs are just docs.
Does it replace Notion or Google Docs?
For engineering specs and knowledge, that's the intent - the comparison is in Rezee vs Notion + Slack. For company-wide non-engineering wikis, general-purpose tools still have the edge.