Turn proposals into interactive blueprints—searchable, audience-filtered, annotated docs with optional ChatGPT access.
Get concise advice on choosing the right CMS, understanding migration costs, and avoiding expensive implementation mistakes before they become roadmap problems.
No spam. Unsubscribe anytime.
A long proposal works better as a product than as an attachment: a decision surface, a shared source of truth, and a working document stakeholders keep coming back to for weeks. Treating it that way means building a private, navigable, audience-aware version of the document — one that can be searched, questioned, annotated, and even read by an AI agent with permission — with the PDF generated as a companion export. This post walks through why that shift matters and what it looks like in practice, on a real 41-chapter discovery blueprint I built and shipped for a client.
Moving a proposal from a PDF into something stakeholders actually use day to day isn't a formatting change. I recently rebuilt the delivery format for a multi-week discovery engagement, and the difference showed up almost immediately: people stopped emailing me questions the document already answered, and started using the sidebar to find them.
A 40-chapter discovery blueprint reads closer to an internal product docs site than a brochure, and a PDF handles that job poorly on several fronts.
Depth stays fixed for every reader, so an executive either wades through implementation tables or an implementer gets a summary with no detail to act on. Finding a specific point means scrolling and hoping you remember which heading held it, or running Ctrl+F across dozens of pages. Clarifying a recommendation means emailing the author, even when chapter 12 already covers it. Review comments end up scattered across email threads, sticky notes, or a separate spreadsheet, disconnected from the passage that prompted them. And the file has no way to meet stakeholders inside the AI tools many of them already use for work.
Every one of those breakdowns traces back to how the document gets presented, independent of how carefully it was written.
Product teams solved this problem years ago for complex systems: a docs site with sidebar navigation, search, deep links, audience modes, and often an assistant that answers from the docs themselves. A proposal deciding a project deserves the same medium.
When a stakeholder opens the blueprint I built, the first screen teaches the format rather than dumping a table of contents on them. A once-per-browser welcome dialog introduces the capabilities that make the format worth using — choosing a view, searching the blueprint, asking the blueprint questions, adding feedback — with an optional path to connect ChatGPT through MCP, and a clearly labeled escape hatch for anyone who still wants a PDF.
That framing sets the tone from the first screen: an invitation into a better working surface, delivered before any content shows up.
The same Markdown source powers three views, and switching between them happens from the sidebar, all backed by the same underlying file.
| View | Who it serves | What they see |
|---|---|---|
| Executive | Decision-makers | Recommendations, BLUF summaries, rationale, tradeoffs, roadmap, risk summaries |
| Reference | Implementers and technical leads | Inventories, matrices, schema detail, supporting evidence |
| Full | QA and authors | Everything in the document |
One shared document carries all three views. Stakeholders share a single URL and change depth in the sidebar as their needs shift. Chat retrieval honors the same filter an Executive-view reader has selected, so a session in that view surfaces Reference-level detail only after the reader switches to Full.
Authoring for this well is an editorial skill more than a technical one. Content gets tagged decision, reference, or both deliberately during writing, and anything left untagged shows up in both the decision and reference views by default.
Chapters live in a sidebar, each page carries its own in-page table of contents, related-chapter links, and prev/next navigation. A 41-chapter blueprint becomes something a reader browses the way they'd browse a product docs site, moving directly to the chapter they need instead of scrolling a single long binder.
"Ask the blueprint" is a retrieval-grounded assistant scoped entirely to the proposal text. Every material conclusion is expected to carry a stable source id, such as [§27:editable-and-locked-boundary], and the interface turns each one into a clickable citation chip. The model is instructed to separate confirmed facts from recommendations, assumptions, drafts, and open decisions, and to say plainly when the blueprint doesn't answer a question yet.
That distinction — say what's known, cite it, and name what isn't decided — is what lets a stakeholder act on an answer without re-reading the source chapter first.
Completed answers offer optional text-to-speech narration for anyone who wants to listen instead of read. The written answer stays the record of what was actually said.
Reviewers select a passage or leave page-level feedback, and each comment routes into a review workflow. The canonical Markdown stays exactly as the author left it, and every comment stays attached to the specific passage that prompted it.
For stakeholders already working inside ChatGPT, the portal exposes a read-only MCP server behind OAuth consent. Once a stakeholder approves the connection, the assistant can list chapters and pull clean chapter Markdown on request. The welcome dialog includes a short setup walkthrough for connecting the tool and referencing it with @ inside a chat.
Through MCP, the proposal becomes a resource an agent can request directly, gated by authentication and explicit permission on every read.
PDF editions — Executive, Reference, and Full — still exist as companions, earning their place in the specific situations below.
| Situation | Best format |
|---|---|
| Offline reading, no internet access | |
| Legal or compliance archive | |
| Counterparty requires an email attachment | |
| Short document, single linear read | |
| Multi-audience, multi-week discovery blueprint | Interactive portal |
| Ongoing reference during a live engagement | Interactive portal |
| Needs search, chat, or feedback on specific passages | Interactive portal |
The PDF editions serve as companion exports for offline reading and archives. The interactive blueprint is where the actual work of reviewing and deciding on the proposal happens.
One canonical Markdown source feeds both the PDF pipeline and the web portal, and the portal never forks chapters into a separate CMS. That constraint forces a better authoring habit: write structured chapters with clear headings and intentional audience tags, prefer blocks that carry real meaning — BLUF summaries, scope tables, timelines, callouts — over walls of prose, and present each reader in the medium that fits them, web first for active work and PDF second for portability.
Higher value in a proposal like this comes from shorter paths to the right depth, with provenance ready the moment someone asks a hard question.
Does this replace the PDF entirely? No. PDF editions stay available as companions for offline reading, archives, and situations where a counterparty needs a file attachment. The interactive portal carries the primary reading and review experience for the engagement itself.
How do stakeholders switch between the executive and reference views? A view switcher in the sidebar changes the depth shown, backed by the same underlying document. Nothing about the switch changes the URL stakeholders share with each other.
Can the AI assistant make up information that isn't in the proposal? The system prompt scopes it to the synced proposal content and requires a source citation on every material conclusion, and it's instructed to say directly when the blueprint doesn't cover a question. Citations resolve to real chapter anchors rather than generated links.
Does connecting ChatGPT through MCP expose the proposal publicly? No. The MCP server sits behind OAuth consent, so a stakeholder has to authenticate and explicitly approve the connection before an agent can read anything.
Is this only useful for very long proposals? The gain scales with length and audience diversity. A short, single-audience proposal may do fine as a PDF. A multi-week discovery document with several stakeholder types and a lot of supporting detail is exactly where the interactive format earns its cost.
A long proposal loses most of its value the moment it becomes a PDF that different stakeholders read at different depths, ask the same repeated questions about, and leave feedback on in disconnected threads. Rebuilding it as a private, audience-aware, searchable, and askable document — with the PDF kept around as a companion export — solved that for a real 41-chapter discovery blueprint. The core idea travels well beyond this one project: present a decision-critical document the way product teams present complex systems, and let the format itself do part of the work of getting stakeholders to the right answer faster.
The technical build behind this — Next.js, Fumadocs, grounded chat, dual auth, and MCP — is covered in the companion post: How I built a private interactive proposal portal.
Let me know in the comments if you have questions, and subscribe for more practical development guides.
Thanks, Matija