Ask ten writers what they draft in and you will get ten answers, several delivered with more conviction than the subject deserves. One swears by a single plain text file and a keyboard shortcut. Another opens a writing app with a binder full of scenes, notes and a word-count target. Both are right — for the project in front of them. The question worth answering is narrower: which tool fits the draft you are sitting down to write this week?

Two families of tools, two sets of habits

Dedicated writing apps — Scrivener, Ulysses, Dabble, yWriter and their many relatives — are built around projects. They hold scenes, chapters and research in one place, count words per section, and export to whatever shape you need at the end.

Plain text editors — Notepad, TextEdit, iA Writer, FocusWriter, BBEdit, Vim — are built around a cursor and a blank page. Formatting, if it exists at all, is Markdown: a few hashes and asterisks. There is no project, only files.

That difference sounds technical. In practice it shapes how you write, and how quickly you start.

Where dedicated apps earn their keep

Anything long enough to get lost in.

The obvious win is structure. Rearranging chapters in a binder is drag-and-drop; in a single 90,000-word document it is cut, scroll, paste, and hope you landed in the right place. If you write out of order — and most novelists do — a scene list lets you jump to the confrontation or the argument you actually feel like writing today, rather than the scene that happens to come next.

Then there is context. A research folder sitting beside the manuscript means the half-remembered detail you need — the layout of a hospital ward, the model of a car, the name of a street — lives next to the scene that uses it instead of in a separate document you forget to open.

The quieter features matter later

Word targets, snapshots that save a version before you cut a paragraph you might want back, per-scene counts, and a compile step that turns thirty files into one manuscript. None of these help you write sentence one. All of them help you finish.

Where plain text wins

Speed, durability and no lock-in. A text file opens instantly, weighs almost nothing, and will still open in a decade on a machine you have not bought yet. Any device, any editor, no import wizard, no conversion dialogue. If you have ever tried to open an old project file in a new version of the software that made it, you know why this matters.

The other advantage is the absence of settings. There is nothing to configure, so there is nothing to configure instead of writing. A blank page with a blinking cursor is the least interesting thing in the room, which is precisely the point.

Markdown is enough for a draft

A hash for a heading, asterisks for emphasis, a blank line between paragraphs. That covers almost everything a draft needs to communicate about its own shape. It is also little enough that you cannot spend an afternoon choosing fonts.

The distraction argument cuts both ways

The usual claim is that plain text keeps you focused while feature-rich apps tempt you into fiddling. There is truth in it, but it is not the whole story.

Plain text has its own traps. You can spend a pleasant hour building a folder structure, inventing a file-naming convention, hunting for the right directory, or migrating everything to a new editor because someone on a forum preferred it. Writers who use plain text for long projects often end up rebuilding, badly, the features a writing app would have given them.

Dedicated apps have the more obvious traps: compile settings that swallow a weekend, template rabbit holes, colour-coding the binder, watching the word-count bar instead of writing the next sentence.

A useful rule: whichever tool leaves you with fewer decisions before the first sentence is the tool for today.

Matching the tool to the draft

• Novel, memoir, thesis, anything chaptered: a dedicated app. The structure pays for the learning curve.
• Short story, essay, single article: plain text. Scaffolding is just weight at 2,000 words.
• Blog posts and newsletters: Markdown in a plain text editor, especially if links, headings and code snippets are involved.
• Series or non-fiction with continuity notes: an app with a research folder, so names, dates and details stay in one place.
• Writing on trains, phones or borrowed laptops: whatever syncs without argument — usually plain text.

Notice that these are about the shape of the work, not your identity as a writer. Plenty of people draft a novel in plain text files, one per scene, named 01-arrival.md, and assemble them at the end. It works. It is simply more admin.

A workflow that survives contact with reality

A hybrid suits many writers. Outline in plain text, because outlining is thinking and thinking is fast. Draft in whichever tool you have chosen. Then export the finished draft to plain text as an archive, so your words never live only inside software you might one day stop paying for.

Before you commit to anything, run a short test with real work rather than a throwaway file:

1. Write 2,000 words of the actual project in it.
2. Reorder two sections and check nothing breaks.
3. Export to the format you genuinely need — DOCX, PDF, standard manuscript layout — and open the result.
4. Close it mid-sentence, reopen, and see whether it restored where you were.
5. Search for a phrase you know is in there, in a document you have not looked at for a week.
6. Leave it alone for seven days, then come back and see whether you remember how it works.

If a tool fails step three or step six, it will fail when you are tired, behind schedule and least able to work around it.

Pick one and stop shopping

Give your chosen tool two weeks of real drafting before you judge it, and resist the urge to switch mid-draft. Migration always costs more words than it saves, and no editor has ever finished a chapter for you.

Whatever you use, back it up. Two copies, one of them off the device, and a plain text export of anything you would hate to lose. Tools are replaceable. Drafts are not.

Photo: theglassdesk / Pixabay