MD Reader — User Insights & Requirements

Source: X/Twitter thread on Notion shipping read-only .md file opening. The replies are a free focus group — people volunteering exactly what they wish an MD tool did, plus naming the competitors they already use. Mined below for a best-in-class reader (paste-from-dev-tools first).

Section 1 — User Insights (what the thread actually reveals)

1. "Read-only" is the loudest complaint — but it's a trap for a reader

The single most-repeated reaction was frustration that Notion's feature is view-only:

• "Make them editable and then we're talking." — @ContinuumCode
• "Why just read only?" — @lamrin
• "Copy to markdown would be 👌" — @BrianBolze
• "Also export as .md?" — @_08tech

Insight: Users don't actually all want a full editor. Parsing the complaints, three distinct jobs hide under "editable": (a) copy the rendered/source back out cleanly, (b) export/round-trip to .md, (c) real inline editing. For a reader, you can satisfy (a) and (b) — which silences most of the noise — without becoming an editor. That's the cheap win.

2. The real pain is scattered files, not single files

• "how much of the pm/eng workflow lives in scattered .md files across repos and local folders." — @ProductLens_
• "Can I open a workspace folder and list all mds?" — @lamrin
• "point to a folder of MD files and they would get added and synced… add my Obsidian vault by pointing to the main folder." — @HeyRyanWhite

Insight: The unit of value isn't "a file," it's a folder / vault. Single-file paste is the entry drug; folder-open + list + navigate is what makes it sticky. This is also the Obsidian-shaped gap everyone keeps gesturing at ("catching up with Obsidian" — @iamerickdamon).

3. Fidelity on migration is the trust-killer

• "does md import keep frontmatter and relative links, because migrations break there" — @sebuzdugan

Insight: This is the most technically specific — and most important — reply in the thread. The two things that reliably break MD tools are YAML frontmatter and relative / wiki links ([[...]], ./path.md). A reader that renders these correctly (frontmatter as a clean metadata panel, relative links as working in-app navigation) instantly out-classes the "just dumps raw text" crowd.

4. The source is increasingly AI/dev-tool output

• The user's own stated use case: "paste from dev tools etc."
• "Markdown is becoming the bridge between AI and productivity… the easier it is to move AI-generated content into your workspace, the faster ideas become actionable." — @GRO_REAST
• HackMD, "dev tools," code write-ups all appear.

Insight: The dominant input is now pasted AI output and dev-tool exports — meaning heavy code blocks (syntax highlighting), tables, task lists, and GFM must be flawless, and paste (not file-open) is the primary intake path. Optimize the clipboard flow ruthlessly: paste → instant clean render, zero setup.

5. There's a live competitive set — and users name it unprompted

Named in-thread: Obsidian, PenDown (Mac MD editor), markdownbird.com ("is better"), zennotes.org, Doc2MD (PDF/DOCX→MD), HackMD. Notion itself is the incumbent people are dunking on.

Insight: The bar for "just renders markdown" is already met by many tools; users switch on UI quality ("the best UI for it was always Notion" — @gauravshetty4) and friction ("I hate opening md files on different apps"). Best-in-class = fastest, prettiest, least setup — not most features.

6. Adjacent asks that hint at roadmap (not v1)

• Sync, not import — "edit Google Drive md files directly, rather than import" (@lance_lz_kong); "synced" (@HeyRyanWhite).
• Conversion in — PDF/DOCX → MD (Doc2MD interest).
• Pure-markdown pages, no blocks — "pages that are pure markdown… No blocks" (@rocarvaj) — a rejection of the Notion block model.
• SEO angle — ".md really matters for seo" (@iSanjayJoshi) — signals a publish/share use case.

Section 2 — Requirements (prioritized for a best-in-class reader)

P0 — Must-have (this is the product)

P1 — Strongly wanted (turns a viewer into a tool people keep)

P2 — Roadmap / differentiators (not v1, but claim the direction)

Explicit non-goals to protect the "reader" positioning

• Don't become a block editor (users explicitly reject Notion's block model — @rocarvaj).
• Don't gate the core loop behind accounts, folders, or sync — paste must work in one action.
• Don't ship a mediocre editor to answer "editable"; ship excellent copy/export instead (satisfies most of that demand at a fraction of the cost).

One-line strategy takeaway

The thread says: everyone can render markdown; nobody does it beautifully with zero friction while respecting frontmatter, relative links, and folders. Win on paste-speed + fidelity + typography first, then folder/vault, then sync — and resist turning the reader into an editor.