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 is not an attachment. It is a product: a decision surface, a shared source of truth, and a working document stakeholders will return to for weeks.
For years the default was the same. Write a careful discovery or SOW, compile a branded PDF, email the link, hope people read it. They skim. They lose the thread between chapter 7 and chapter 31. They ask the same questions in Slack that the document already answers. When one person needs the executive view and another needs the field matrix, you send a second PDF — or worse, one overloaded PDF that serves nobody well.
I stopped treating the PDF as the primary artifact.
I still generate PDFs. They are useful. They are no longer the product.
The product is a private interactive blueprint: the same canonical Markdown, presented as a documentation site that people can navigate, filter by audience, search, ask, annotate, and — when it helps — pull into ChatGPT with consent.
A 40-chapter discovery blueprint is not a brochure. It is closer to an internal product docs site that happens to decide a project.
In a PDF:
None of that is a writing problem. It is a presentation problem.
Product teams already know how to present complex systems. They ship docs sites: sidebar navigation, search, deep links, audience modes, sometimes an assistant that answers from the docs.
Proposals deserve the same medium.
When a stakeholder opens the blueprint, the first screen should teach the medium, not dump a table of contents. In the portal I built, a once-per-browser welcome dialog greets them with:
Welcome to the interactive blueprint
Then it shows the capabilities that make the format worth using: choose your view, search the blueprint, ask the blueprint, add feedback — plus an optional path to connect ChatGPT via MCP, and a clear escape hatch labeled Prefer PDFs? for people who still need a static file.
That framing matters. You are not apologizing for not sending a PDF. You are inviting them into a better working surface.
Skip the feature list as a list of features. Each capability exists to change how stakeholders use the document.
Chapters live in a sidebar. Each page has an in-page table of contents, related-chapter links, and prev/next. A 41-chapter blueprint becomes browsable the way a product docs site is browsable — not a single scroll through a binder.
The same Markdown source powers three views:
Audience is a view switcher, not three forked documents. Stakeholders share one URL. They change depth in the sidebar. Chat retrieval follows the same filter, so an Executive session does not quietly pull Reference-only detail unless they switch to Full.
Authoring this well is an editorial skill. You tag content with decision, reference, or both on purpose. Untagged content appears in both decision and reference views — there are no smart defaults that guess for you.
“Ask the blueprint” is not a generic chatbot bolted onto a website.
It answers from the proposal text. Every material conclusion is expected to cite a stable source id (for example [§27:editable-and-locked-boundary]). The UI turns those citations into clickable chips. The model is instructed to distinguish confirmed facts, recommendations, assumptions, drafts, and open decisions — and to say when the blueprint does not answer the question.
That is the difference between an assistant that helps stakeholders work the document and one that invents confidence.
Optional Listen narration is available for completed answers when someone wants to hear the response. The written answer remains the source of truth.
Reviewers can select a passage, leave a comment on that exact text, or leave page-level feedback. Comments go to a review workflow. They do not silently edit the canonical Markdown.
The document stays authoritative. Feedback stays attached to the passage that prompted it.
For stakeholders who already work in ChatGPT, the portal can expose a read-only MCP server. After OAuth consent, tools can list chapters and fetch clean chapter Markdown. The first-run welcome dialog includes a short setup carousel for connecting the plugin and referencing it with @.
The proposal stops being a file you upload into a chat. It becomes a resource the chat can request, with authentication and explicit permission.
Executive, Reference, and Full PDF editions still exist as companions. Offline reading, legal archives, printouts, and “just email me the file” culture are real. The welcome dialog says so plainly: explore in the app, or use the PDF editions when a static document is easier.
The PDF is a export. The interactive blueprint is the product.
The technical constraint that makes this honest: there is one canonical Markdown source. The PDF pipeline and the web portal both read it. The portal never forks chapters into a CMS.
That forces a better authoring habit:
Higher value is not “more pages.” Higher value is shorter paths to the right depth, with provenance when someone asks a hard question.
Keep PDFs when:
Do not keep PDFs as the primary medium for multi-audience, multi-week discovery blueprints. That is where interactive presentation earns its keep.
If you sell with long proposals, SOWs, or discovery docs, treat presentation as part of the offer:
The stack that implements this — Next.js, Fumadocs, grounded chat, dual auth, MCP — is a separate story for builders.
Technical companion: How I built a private interactive proposal portal
| View |
|---|
| Who it serves |
|---|
| What they see |
|---|
| Executive | Decision-makers | Recommendations, BLUF, rationale, tradeoffs, roadmap, risk summaries |
| Reference | Implementers / technical leads | Inventories, matrices, schema detail, evidence |
| Full | QA and authors | Everything |