A friend of mine, a novelist who has published two books I would happily recommend to anyone, asked me last winter to look at her Notion workspace. We sat at the kitchen table, the kettle on, the rain doing its quiet November work outside the window. She turned the laptop toward me with the apologetic face writers reserve for confessing to their tools. There were, by her own count, twenty-three databases. There was a "Quotes" database with eight hundred entries. There was a "Settings" database for the novel she had finished three years ago. There was a database called "System" whose purpose neither of us could identify.
What I told her, and what I want to say to you, is that a working writer needs three databases in Notion. Not five, not ten, not twenty-three. Three. Everything else is decoration, or an artifact of someone else's workflow that you have inherited without testing it against your own. This essay is the long argument for those three, in the order you should build them, with the reasoning underneath. By the end I hope you will, like my friend did over the second pot of tea that afternoon, feel quietly relieved.
If you would like to skip ahead and look at the workspace built around exactly these three databases, you can try the Notion template I use here →. The walkthrough below explains why each one earns its place.
The premise: what a writer's workspace is for
A writer's workspace is for three things, and only three things. It is for catching what arrives — the overheard phrase, the half-formed idea, the email from a reader that contains a future essay. It is for moving things from caught to written — drafts in their various unfinished states. And it is for finding what has already been written, both the writer's own published work and the research that fed it. Catch, draft, retrieve. That is the whole job.
Notion templates marketed to writers tend to add layers above this — character sheets, world bibles, plot grids, mood boards, beat outlines, productivity dashboards. For some writers, on some projects, these have a place. For most writers most of the time, they are scaffolding for a building that has not been started, and they consume the attention that should have gone into starting it. The three databases below are the load-bearing structure. Anything else should be added only after they have been working for at least three months.
This argument extends, by the way, the same logic I have applied to kakeibo in the kakeibo Notion template essay — that the simplest version of a practice is almost always the version that compounds. Complexity is bought with attention, and attention is the writer's only capital.
1. The Inbox
One database. One field that matters: a long-text note. Optional fields: date (auto-filled), source (where the note came from — overheard, from a book, from a reader, from my own thinking), and a checkbox called used.
The Inbox is where everything that arrives during the day goes. Half-thoughts, quotations, sentences I want to use someday, ideas for essays, single words that interest me. The rule is that nothing is too small to enter. The other rule is that nothing is sorted on the way in. The Inbox is, deliberately, a single undifferentiated stream.
The reason this works, where the elaborate "second brain" systems of the past decade do not, is that the cost of entry has to be near zero or the writer will not capture. A note that requires three property selections and a tag will not be made; the thought will be lost. A note that requires only typing into a single field will be made, and over months the Inbox becomes the most valuable database in the workspace. Mine, after three years, contains roughly four thousand entries. Perhaps a hundred of them have produced essays. The other three thousand nine hundred are not waste; they are the topsoil from which the hundred grew.
What the Inbox is not for
The Inbox is not a task list. It is not a project board. It is not a place where things wait to be done. Most of what enters it will never become anything, and that is the correct outcome. The Inbox's job is to make sure the few things that could have become something do not get lost in the moment of arrival. Tasking it up with anything more turns it into a queue, and queues, for most writers, become guilt.
How to process it (lightly)
Once a week — Sunday morning, with coffee, the same time I do the kakeibo weekly check-in described in the kakeibo template essay — I scroll through the new Inbox entries. Anything that has clearly graduated into a draft idea gets moved to the Pieces database, with the Inbox entry marked "used." Everything else is left exactly where it is. The Inbox is not pruned. The undeleted residue is, over time, where the unexpected essays come from.
2. Pieces (the drafts database)
One database, one row per piece of writing in any unfinished state — from "this is an idea" through "drafted" to "submitted." Fields: title, state (idea, drafting, edit one, edit two, submitted, scheduled), destination (Mindful Yen, Substack, a specific publication, "no home yet"), commission deadline if any, and the long-text body of the draft itself.
The Pieces database is the workshop. It is where ideas migrate when they have outgrown the Inbox, and where they live until they are published. The reason it is one database and not several — not "ideas," "drafts," "essays in progress," "pitched but not commissioned" — is that the boundary between those states is genuinely blurry, and forcing the writer to make the categorisation slows down the only thing that matters, which is moving the piece one state forward.
I write the actual long-form drafts in iA Writer, in plain Markdown, and paste the finished draft into the Pieces row at the editing stage. I have been honest about this elsewhere, in the freelance writers' setup; Notion is a wonderful editing and archiving environment and a slightly clumsy long-form drafting one. The database holds the record. The drafting tool is whatever produces the most writing per hour. Trying to make Notion be both is a familiar trap.
The view I open most often is "everything not yet submitted, sorted by deadline ascending, then by state." That view is the studio's heartbeat. It tells me what is closest to done, what is closest to overdue, and what has been stuck in the same state for longer than it should have been. If a piece has been in "edit one" for three weeks, the view makes that visible without judgment, and the visibility is what eventually moves the piece. No automation needed. The dashboard is the discipline.
The state field done well
I would gently caution against having more than six states. My friend's workspace had eleven, including separate states for "first draft," "first revision," "second draft," "second revision," and "stewing." The states had stopped meaning anything; she was choosing them by mood. Six states or fewer keeps the field useful. If you find yourself adding a seventh, two of the existing six probably mean the same thing.
3. The Library
One database. Two kinds of entry: published pieces of your own writing, and research notes from other people's. Fields: title, type (own work, book, essay, interview, primary source, other), author, year, tags (kept deliberately spare — perhaps a dozen across the whole database), summary (one paragraph, in your own words), and quotes (long-text, with whatever marginalia you want).
The Library is the writer's memory. It is where finished pieces go to be findable later, and where the books and essays that fed those pieces are kept in a form you can search. The unification — own work and research in the same database — is, I think, the single most important structural choice. It makes the writer's voice and the writer's reading legible to each other. When I am drafting a new essay and I search the Library for "kakeibo," what comes back is both my own previous essays on the topic and the books and articles I drew from. That conversation, in one search result, is what compounds.
The "summary in your own words" field is the one most writers skip and most need. Copying a quote into a database is a clerical act. Writing a one-paragraph summary in your own words is an act of comprehension, and the comprehension is what makes the source actually usable later. The Mueller and Oppenheimer 2014 study on note-taking that I have cited elsewhere applies as cleanly to digital reading notes as it did to lecture notes. Verbatim is unhelpful. Restatement is the work.
What about a separate "ideas" or "themes" database?
Resist it. The themes a writer is genuinely working on emerge from the cross-references between Inbox, Pieces, and Library. They are not a separate dataset. A "themes" database, in my experience, becomes either a redundancy of what is already in Pieces or a wishlist of essays the writer would like to have written but has not. Either failure mode is a guilt object. The three databases above produce themes naturally, in the form of essays that get written. That is the only reliable signal.
How the three talk to each other
The cross-references are simple, almost embarrassingly so, and that simplicity is the point.
An Inbox entry, when it graduates, becomes a Pieces row. The original Inbox entry is marked "used" but not deleted, because the original phrasing of an idea is sometimes worth retrieving even after the essay it produced is finished.
A Pieces row, when the essay is published, becomes a Library row of type "own work." The draft body in Pieces is replaced with a link to the published version. The Pieces row is then archived. This migration takes about ninety seconds per published piece and ensures that finished work lives in the Library, not in a perpetually growing drafts database.
A Library row of type "book" or "essay" is referenced from any new Pieces row that draws on it, by linked relation. After three years this network of references becomes one of the most useful artifacts in the workspace — I can ask, of any source in my Library, which of my own essays drew on this, and the answer is one click. I can ask, of any of my own essays, what did I read while writing this, and the answer is the same one click in the other direction.
None of this requires automation. None of it requires anything beyond the three databases and Notion's native relation property. The compound interest is in the discipline of doing the migrations, weekly, when the Inbox is processed.
What deliberately does not get its own database
For honesty, a short list.
A quotes database. Quotes live in the Library entry of the source they came from. A quote without a source is an Inbox entry. There is no third place.
A character or setting database, even for fiction writers. These belong inside the Pieces row of the work they serve. A separate database makes sense only if a single character or setting recurs across many works, which is a problem only a handful of writers actually have.
A "writing prompts" or "essay ideas" database. These are Inbox entries. The whole point of the Inbox is that it does not need a sibling.
A productivity tracker. Word counts, daily streaks, hours-at-desk. None of this changed what I wrote next. The monthly reflection — which lives outside this three-database setup, in the broader workspace I described in the solo creator essay — surfaces what actually matters about a writing month, in writing, once a month. That is the right cadence.
The home page
The home page of the writer's workspace is built from two linked views: "Pieces, sorted by deadline" and "Inbox, last seven days." That is the entire home page. Two views. No dashboard, no progress bars, no inspirational quote, no calendar embed. The reason is that a writer's home page should be the first surface the writer's eye lands on, and the first surface should show only what is actually being worked on now and what has just arrived. Anything else is noise dressed as useful.
I have, of course, tried more elaborate home pages. They were all eventually removed. The home page that looked most impressive was also the one I opened least, because it made me feel observed rather than helped. A writer's workspace, like a writer's desk, should be quiet enough to think in.
If you build only one of the three
Build the Inbox. It is the database with the lowest cost of entry, the highest cost of absence, and the one whose value compounds fastest. A writer with only an Inbox and a paper notebook is better equipped than a writer with twenty-three Notion databases and no Inbox. I have watched both situations from close range, in correspondence with readers and around my own kitchen table, and the pattern is consistent.
The Pieces database can be added in the second month, once the Inbox has produced its first graduates. The Library can be added in the third month, once the first essay has been published into it. The full setup is a three-month build, not a one-day one, and that pacing matches the actual rhythm at which a writing practice deepens.
If you would like the workspace I keep — three databases, two-view home page, on the free plan — you can download the Notion template I use here →. It is the version I have refined over three years and reset annually using the koromogae ritual described in the workspace reset essay. It has stayed roughly the same size for two years now, which is, in the end, the only metric of a workspace that matters.
One closing thought, from my friend's kitchen table
What my friend did, that rainy November afternoon, was not adopt a new system. We did not build her a new workspace from scratch. We took the twenty-three databases she had and merged twenty of them into the three I have just described. The "Quotes" database became the quotes field on Library entries. The "Settings" database for the finished novel became part of that book's Library entry, type "own work." The mysterious "System" database we deleted, after agreeing that neither of us could remember why it had been made.
By the end of the second pot of tea, her workspace was three databases and a home page. She wrote, the following month, more than she had written in the previous six. The workspace had not made her a better writer. What it had done was stop competing with the writing for attention, which is a more modest claim and, I think, the only honest one a tool can make.
If you find this useful, I write more about the daily texture of a small writing practice in the Mindful Yen Substack, and the printable kakeibo journal in my Etsy shop is the paper companion to the financial half of the workspace. Either is a fine place to continue the conversation.