For long-form writing, a Notion doc fights you; Markdown gets out of the way

I spent two weeks last month writing the same 4,000-word strategy memo twice. Not because the first draft was bad — because I wrote the first one in Notion and the second in a plain Markdown file, and somewhere around paragraph thirty I realized the tool was costing me more than the thinking was.

This is not a "Notion is bad" post. Notion is excellent at the thing it was designed for: relational databases, team wikis, linked pages, a living knowledge base that fifteen people edit. The trouble starts when you take a tool optimized for structured collections of small things and ask it to hold one long, continuous argument. The friction isn't a missing feature. It's the data model.

A block is an object. A memo is a stream.

In Notion, every paragraph, heading, and bullet is a discrete block — a draggable, selectable, individually-addressed object. That is exactly what you want when you're assembling a dashboard of database views or a wiki page with embedded calendars. It is exactly what you do not want when you are trying to write prose that flows from one idea into the next.

Long-form writing is a single text stream. You read it top to bottom. You revise by sweeping across sentence boundaries — deleting half of one paragraph and the start of the next, merging two thoughts, splitting one. A text stream lets you do that with a cursor. A block editor makes you negotiate object boundaries first.

The four taxes I actually paid

Concretely, here is what slowed me down in the Notion draft. None of these is a dealbreaker on its own. Together, on a 4,000-word piece, they added up to a constant low-grade tax on attention.

1. The block-drag tax

Because every paragraph is a draggable object, the handle that reorders blocks lives right where my cursor goes when I reach to select text. I lost count of how many times I picked up a paragraph and dropped it three blocks down by accident, then had to find it and drag it back. On a wiki page with eight blocks, you'd notice instantly. In a 60-paragraph memo, a paragraph can silently land in the wrong section and you don't catch it until a re-read. The model treats reordering as a first-class gesture — but when I'm writing prose, reordering is rare and typing is constant, so the defaults are backwards for the task.

2. Losing the outline when you nest toggles

Notion's toggles are great for collapsing a wiki. But the moment I tucked a sub-argument inside a toggle to "clean up" the draft, those headings dropped out of the document outline and the table of contents. My structural skeleton — the thing I navigate a long piece by — became partially invisible. In a single Markdown stream, an ## is an ## wherever it sits. There is no nesting that can hide it from the outline, because the outline is the heading lines.

3. Copy-paste mangling across block boundaries

Moving text between blocks — or pasting a chunk from one section into another — frequently broke formatting. A pasted list would inherit the wrong block type; a quote would absorb the paragraph after it; pulling text out of a callout would leave the callout as an empty husk I had to delete separately. Every paste was a small cleanup job. In a Markdown file, paste is paste: characters in, characters out.

4. The slash-menu interrupting flow

The / menu is genuinely good for inserting a database or an embed. But in prose I don't insert databases — I write sentences. And when a sentence starts with a fraction or a path and I type "/", the menu pops up and steals focus mid-thought. Flow writing wants the keyboard to disappear. A block editor keeps gently reminding you it's there.

The same 600 words, side by side

Here's the part that made the difference concrete for me. Take one ~600-word section of the memo. In Notion, structurally, it is a stack of addressable objects — something like this (simplified to show the model, not the rendering):

[heading_2]   block: "Why we're consolidating the two pipelines"
[paragraph]   block: "We run two ingestion paths today. The first…"
[paragraph]   block: "The second was built for the 2024 launch and…"
[callout]     block: "⚠️ Note: the 2024 path still owns billing events."
  [paragraph]   nested block: "Migrating those needs a freeze window."
[bulleted]    block: "Cost of keeping both: duplicated on-call…"
[bulleted]    block: "Cost of merging: one freeze, ~3 eng-weeks…"
[toggle]      block: "Detail: the freeze sequence"   ← heading hidden from outline
  [heading_3]   nested block: "Step order"
  [numbered]    nested block: "Drain the queue"
  [numbered]    nested block: "Flip the writer…"
[paragraph]   block: "Recommendation: merge in Q3, accept the…"

Every line above is a thing I can drag, and the [toggle] quietly removed Step order from the document outline. To rewrite this section I'm editing eleven objects, minding their boundaries.

Here is the identical section as a single Markdown text stream:

## Why we're consolidating the two pipelines

We run two ingestion paths today. The first handles real-time
events and has been stable since launch. The second was built
for the 2024 launch and now mostly duplicates the first.

> Note: the 2024 path still owns billing events, so migrating
> those needs a dedicated freeze window.

- **Cost of keeping both:** duplicated on-call, two schemas to
  reason about, drift between them every quarter.
- **Cost of merging:** one freeze window, roughly 3 eng-weeks,
  and a one-time billing reconciliation.

### Detail: the freeze sequence

1. Drain the queue.
2. Flip the writer to the unified path.
3. Reconcile billing events from the cutover window.

**Recommendation:** merge in Q3, accept the freeze, retire the
2024 path before the holiday code freeze makes it permanent.

It's the same content. But the second version is one continuous thing. Every heading is visible in the outline because the heading line is the outline. I revise it with a cursor, not by negotiating with objects. And — this is the part that matters in 2026 — I can hand the entire stream to an AI and say "tighten the argument, keep the recommendation," and it rewrites in a single pass. There are no block boundaries to preserve, no nesting to flatten and rebuild, no callout husks left behind. A block document forces an AI (and you) into block-by-block edits; a text stream is the native unit both a model and a writer think in.

So where does the shareable link come from?

The usual objection to "just write Markdown" is real: a .md file is not something you can send to a stakeholder. They want a link they can open, not a raw text file or an attachment they have to render. That objection is exactly why people reach for Notion in the first place — Notion gives you the link.

My current workflow keeps the text-stream authoring experience and still ends in a link. I draft in Markdown in whatever editor disappears for me, then let Plain render that same Markdown into a shareable doc — a long-form reading layout at a URL. There is no export step, no "publish to web" toggle that produces a second, divergent copy. The document and the link are the same object, which is the whole premise of the document is a link: the artifact you write and the thing you send are one and the same, and the Word/PDF export is a fallback, not the product.

Because the source stays as plain text, it also stays diff-able — I can see exactly what a revision changed, line by line, instead of squinting at a block tree that reshuffled itself. That's a separate benefit from the one this post is about, but it falls out of the same decision: keep the source a stream, not a database of blocks.

The honest tradeoff

I want to be precise about when this argument doesn't hold, because the block model isn't worse — it's built for a different shape of work.

Notion wins when the unit of work is a collection of small, related things: a relational database of projects with status and owner fields; a team wiki where dozens of pages link to each other; a CRM-lite, a content calendar, a meeting-notes archive you filter and sort. Anything where structure-as-data is the point, and where many people maintain it together, the block model and the database engine underneath it are genuinely the right tool. You will not replicate that with a folder of Markdown files, and you shouldn't try.

Markdown wins when the unit of work is one author writing one long thing — a memo, an essay, a design doc, a spec, a chapter. Here you don't want structure-as-data. You want a single stream that reads top to bottom, an outline that can't hide from you, a paste that doesn't mangle, and a source an AI can rewrite whole. The block model's strengths become friction, and the friction compounds with length.

The test I now use is simple: am I assembling, or am I arguing? If I'm assembling related items that other people will also touch, I open Notion and I'm glad it exists. If I'm building one continuous argument that has to land with a reader, I write Markdown and let it render to a doc link. Picking the right one isn't about which has more features — it's about matching the data model to the shape of the work, the same way you'd pick a deck, a doc, or a sheet rather than forcing one format to do all three (eight philosophies).

For long-form, the quiet superpower of a text stream is that it never reminds you it's a tool. You type, the words flow, the outline stays honest, and when you're done you send a link instead of a file. A Notion doc can do most of that — but for 4,000 words of one person's argument, you feel every block boundary it asks you to manage. Markdown just gets out of the way.