--- title: "Your Manuscript Never Leaves the Desk: The Case for Local-First Writing Software" url: https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s canonical: https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s language: en published: 2026-10-11T08:43:10.184Z category: "AI for Creators" author: "Mac" summary: "Somewhere right now a novelist is scrolling through a terms-of-service update she did not request. It is eleven paragraphs long, and one of them mentions \"improving our services using content..." html_alternate: https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s llm_index: https://lacunai.com/blog/llms.txt atom_feed: https://lacunai.com/blog/feed.xml --- # Your Manuscript Never Leaves the Desk: The Case for Local-First Writing Software > Somewhere right now a novelist is scrolling through a terms-of-service update she did not request. It is eleven paragraphs long, and one of them mentions "improving our services using content... ## Table of contents - [The Psychology of Creative Custody](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#the-psychology-of-creative-custody) - [Why the violation feels physical](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#why-the-violation-feels-physical) - [The Anatomy of Cloud Vulnerability](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#the-anatomy-of-cloud-vulnerability) - [Your words live on someone else's disk](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#your-words-live-on-someone-else-s-disk) - [Telemetry, syncing, and the data you did not know you were making](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#telemetry-syncing-and-the-data-you-did-not-know-you-were-making) - [Terms change, and so does what "we do not" means](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#terms-change-and-so-does-what-we-do-not-means) - [The copyright dimension](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#the-copyright-dimension) - [The False Dichotomy](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#the-false-dichotomy) - [The offline word processor is not the only safe choice](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#the-offline-word-processor-is-not-the-only-safe-choice) - [The folder-sync workaround is not a clean middle path](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#the-folder-sync-workaround-is-not-a-clean-middle-path) - [The real alternative](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#the-real-alternative) - [What a Local First Novel Writing App Actually Means for a Novelist](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#what-a-local-first-novel-writing-app-actually-means-for-a-novelist) - [Your manuscript is a file on your drive](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#your-manuscript-is-a-file-on-your-drive) - [No network required](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#no-network-required) - [No server-side copy of your raw text](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#no-server-side-copy-of-your-raw-text) - [What local-first does not mean](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#what-local-first-does-not-mean) - [Cutting-Edge Intelligence Without the Leak](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#cutting-edge-intelligence-without-the-leak) - [Route one: ephemeral processing under zero-retention terms](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#route-one-ephemeral-processing-under-zero-retention-terms) - [Route two: bring your own key](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#route-two-bring-your-own-key) - [Route three: models that run on your own hardware](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#route-three-models-that-run-on-your-own-hardware) - [Why this is not a compromise](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#why-this-is-not-a-compromise) - [What the intelligence is actually for](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#what-the-intelligence-is-actually-for) - [Scrivener Cloud Alternatives and the Modern Workflow](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#scrivener-cloud-alternatives-and-the-modern-workflow) - [Why Scrivener won two decades of loyalty](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#why-scrivener-won-two-decades-of-loyalty) - [Where the workarounds start to strain](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#where-the-workarounds-start-to-strain) - [What a local-first alternative actually adds](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#what-a-local-first-alternative-actually-adds) - [Offline manuscript software is a category, not a limitation](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#offline-manuscript-software-is-a-category-not-a-limitation) - [The Creative Custody Checklist](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#the-creative-custody-checklist) - [How to apply it without becoming a full-time auditor](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#how-to-apply-it-without-becoming-a-full-time-auditor) - [The Desk as Sanctuary](https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s#the-desk-as-sanctuary) Somewhere right now a novelist is scrolling through a terms-of-service update she did not request. It is eleven paragraphs long, and one of them mentions "improving our services using content you submit." She has a draft in that service. It is the draft about her mother. She reads the paragraph three times, closes the tab, and does not write for the rest of the night. That is the cost of the modern writing tool. Not a breach. Not a headline. A quiet, private flinch that costs a writer an evening, and then another, and then a little of the nerve the book needed in the first place. This essay is a case for ending the flinch. I should say up front that I am going to be fairly blunt about it. I am blunt because the stakes are your book, and because the industry that builds writing software has spent a decade telling you that privacy and good tools are a trade. They are not. You can have both. The architecture that gives you both has a name: local-first. By the end of this piece you will know what it means, how to test for it, and why a local first novel writing app should be the default for anyone who writes fiction they would hate to see leak. ## The Psychology of Creative Custody Start with the first draft, because that is where the damage happens. A first draft is not a performance. It is a private act of exploration, and it needs the conditions of one. Elena, a hospice nurse who writes literary fiction on the side, told me she writes her worst sentences first, on purpose. She writes the cruel version of her protagonist's father. She writes the sex scene that embarrasses her. She writes the chapter where the narrator thinks something unforgivable. None of it is meant for anyone. Most of it will be cut. All of it has to exist before the good version can. That only works if the page feels sealed. The moment a writer suspects the room has a window, the prose changes. It gets careful. It gets polite. It starts anticipating a reader who is not there, and a writer who is writing for an imagined audience of auditors produces exactly the safe, lifeless sentences that the first draft exists to avoid. Call this creative custody. It is the plain sense that the manuscript is in your hands, and only your hands, until you decide otherwise. Custody is not about secrecy for its own sake. It is about sequence. You decide when the work goes out. You decide who sees it first. You decide what it is allowed to become before the world has a vote. ### Why the violation feels physical Writers describe the loss of that custody in oddly bodily terms. They say they feel exposed. They say they feel watched. They say they feel, and I have heard this exact word more than once, robbed, even when nothing has been taken that they can point to. This is not hysteria. It is an accurate reading of the situation. An unpublished manuscript is the most unfinished, least defended thing a writer owns. It has no cover, no agent, no copyright registration, no reviews to frame it. It is raw. Raw material in someone else's database is raw material in someone else's possession, and the writer knows it. The quiet panic of a terms-of-service update works the same way. You agreed to something once, under a different set of rules, and the rules have now shifted under a book you have been building for three years. You did not consent to the new arrangement. You were informed of it, which is a different thing. (It is a very different thing.) The Authors Guild has spent years on exactly this problem: how author work is collected, copied, and used to train commercial systems without meaningful consent. Whatever you think about where that fight lands, the instinct behind it is sound. Writers are right to want to know who holds their words, and for what. Treat that instinct as professional hygiene, not paranoia. ## The Anatomy of Cloud Vulnerability Before we can talk about the alternative, we need an honest picture of how a typical cloud writing tool works. Not the marketing. The plumbing. ### Your words live on someone else's disk In a standard cloud writing app, the canonical copy of your manuscript is not on your laptop. It is in a centralized database on servers the company controls. Your laptop holds a window onto that database: a cached view, a browser tab, a synced replica. When you type, the keystrokes travel to the server, and the server decides what the truth is. That arrangement has real conveniences. It also means three things worth stating plainly. One: the company holds your complete text, in readable form, as a matter of course. Two: your access to your own book depends on their servers, their billing, and their continued existence. Three: anyone with sufficient access to those servers, whether an employee, a contractor, an attacker, or a subpoena, can reach a copy. ### Telemetry, syncing, and the data you did not know you were making Beyond the manuscript itself sits a second layer of data that writers rarely think about. Modern apps log behavior. Which features you open. How long you sit idle. Where the cursor sits. How large your documents are. Some of this is benign product analytics. Some of it is not benign at all, particularly when the analytics pipeline captures snippets of content for "quality" purposes, or when crash reports bundle the text you were editing when the app failed. Automatic syncing adds its own exposure. Every sync is a transmission. Every transmission is a copy in transit and a copy at rest somewhere else. A writer who thinks of her book as one file on one machine is, in a cloud tool, actually maintaining a small fleet of copies she cannot enumerate. ### Terms change, and so does what "we do not" means Here is the pattern, and it repeats often enough to have a rhythm. A company states that it will not use your content for X. Time passes. The company is acquired, or pivots, or discovers that a new product line needs data. The terms are revised. A notice goes out. Most users do not read it, and the few who do have already invested too much to leave. Notice what I am not saying. I am not saying every cloud company is acting in bad faith. Many are not. I am saying that a promise from a company is only as durable as the company's incentives, and incentives move. A policy is a statement of current intent. It is not a physical constraint. If your safety depends on a promise staying true, you are renting your safety, and the landlord can change the lease. The Electronic Frontier Foundation has documented this dynamic across the consumer software industry for years. The lesson is consistent. When user data sits on a company's servers, user control over that data is contingent. When it sits on the user's own hardware, control is structural. Contingent versus structural. Hold onto that distinction. The rest of this essay hangs on it. ### The copyright dimension There is a legal layer too, and it deserves more attention than it gets. The US Copyright Office has published ongoing guidance on how copyright interacts with generative AI, including questions of authorship, training data, and what protection attaches to machine-assisted work. The details are evolving, and I will not pretend to settle open legal questions in a craft essay. The practical point is simpler. Your unpublished manuscript is your property from the moment you write it. The less of it that sits in systems you do not control, the fewer legal and technical questions you ever have to answer about where it went. Minimizing exposure is cheaper than litigating it. ## The False Dichotomy Now the myth. Writers who have thought about all of this tend to arrive at a bleak conclusion: that they must choose. On one side, the offline tools of an earlier era, plain and safe and a little dead. On the other, the cloud suite that does clever things and watches everything. I would like you not to accept that framing. It is wrong, and it is wrong in a way that benefits the people selling you the second option. ### The offline word processor is not the only safe choice Yes, a bare offline word processor keeps your text private. It also keeps you alone with a blinking cursor and no help of any kind. Nobody wants to rebuild their continuity notes in a spreadsheet and hunt for a dropped subplot by memory. A tool that is safe because it does nothing is not a solution. It is a retreat. ### The folder-sync workaround is not a clean middle path Then there is the improvisation many careful writers settle into: a desktop writing app whose project files live in a synced folder. Dolores, a retired high school teacher drafting her first historical novel, runs exactly this setup. Her project sits in a folder that a consumer sync service mirrors to the cloud and to a second computer. It works until it does not. One afternoon she opens the project on the second machine before the first has finished syncing, saves, and creates a conflicted copy. Now there are two versions of her manuscript with overlapping edits and no clear winner. She spends a Sunday diffing them by eye. And the whole time, her book has been sitting in a third party's storage, which is precisely the thing she was trying to avoid. This is the false dichotomy in miniature. She did not choose surveillance. She did not choose isolation. She chose a patchwork, and the patchwork has the weaknesses of both. ### The real alternative There is a third option, and it is not a compromise between the first two. It is a different architecture, one that was described carefully and in public years ago. It is worth meeting on its own terms. ## What a Local First Novel Writing App Actually Means for a Novelist Local-first architecture: the canonical manuscript file lives on physical hardware rather than a remote database. The phrase comes from a now-famous essay by the research lab Ink and Switch, "Local-First Software: You Own Your Data, in Spite of the Cloud". It is worth reading in full. The authors lay out a set of ideals for software that keeps the speed and ownership of a desktop application while keeping the convenience people associate with the cloud. Among them: the work should be fast, the work should function offline, the work should survive the death of the company that built the tool, and the user should retain ultimate ownership and control of the data. Translate that into the daily life of a novelist and a local first novel writing app comes into focus as something concrete, not a slogan. ### Your manuscript is a file on your drive In a true local-first app, your manuscript lives on your own SSD. The canonical copy is the one on your machine. Not a replica of a server's copy. The original. If the app's company vanished tomorrow, your book would still be sitting there, readable, on hardware you own. The format matters. The best local-first apps store your work in formats that are open and durable: plain text, or a well-documented database. SQLite is the quiet workhorse here. It is a single-file database engine, public domain, built for reliability, and so widely deployed and so carefully documented that the Library of Congress recommends it as a format for long-term data preservation. A novel stored in SQLite or plain text is a novel you can open in thirty years with tools that do not yet exist, because the formats are simple and the specifications are public. Compare that to a proprietary cloud document, which is readable for exactly as long as the vendor keeps the lights on and the export button working. ### No network required A local-first app does not need the internet to do its core job. You can write on a train, in a cabin, in the basement where the signal dies, on a flight over an ocean. Nothing breaks. Nothing waits on a handshake with a server. Writing is instant because it is happening against a local disk, not a round trip to a data center. This is not just a convenience. It is a security property. A tool that functions fully offline is a tool that cannot be forced to phone home in order to work. The network becomes optional, which means any network feature is something you opt into deliberately rather than something you tolerate by default. ### No server-side copy of your raw text Here is the clause that matters most. In a local-first design, there is no company database holding your raw manuscript. There is nothing to breach, nothing to subpoena, nothing to quietly repurpose in a future policy revision. You cannot lose custody of something that never left. That is the structural guarantee I promised earlier. It does not depend on the company's good behavior. It depends on where the bytes physically sit. ### What local-first does not mean Let me bound the idea before it gets mistaken for something else. Local-first does not mean anti-network. It does not mean you can never collaborate, never back up to a service, never share a draft. It means the default is local and the exceptions are yours to make. You can still send a chapter to a beta reader. You can still keep an encrypted backup somewhere offsite. The difference is that you are the one doing it, on purpose, rather than discovering later that it was happening automatically. Local-first inverts the burden. In the cloud model, privacy is something you must hunt down and defend, setting by setting. In the local-first model, privacy is the starting condition, and sharing is the thing you consciously enable. ## Cutting-Edge Intelligence Without the Leak This is the section skeptics skip to, so let me address the objection directly. The objection runs: all of this is lovely, but the useful tools, the ones that can actually analyze a manuscript, require sending your text to a remote AI model. So the choice is privacy or intelligence, and you cannot have both. That is the claim. It does not hold. There are at least three working ways to get serious AI assistance without surrendering custody, and a well-built local first novel writing app uses them. ### Route one: ephemeral processing under zero-retention terms The first approach sends text to a hosted model, but under strict conditions. The text travels only when you ask for an analysis. It is processed in memory. It is not stored, not logged, and not used to train anything. Reputable model providers offer API agreements that contractually specify zero data retention and no training on customer inputs. The manuscript is a visitor, not a resident. It arrives, gets read, produces a result, and is gone. Be precise about what this is and is not. It is not the same as zero transmission. Your text does leave your machine for the duration of the request. What changes is that the leaving is deliberate, scoped to a single task, and governed by terms that forbid retention. For many writers that is an acceptable trade for the quality of the analysis. For others it is not, which is why the second and third routes matter. The right question for any app using this route is specific: what is sent, when, to whom, and under what retention terms? A good app answers in plain language, without making you dig through a policy. ### Route two: bring your own key The second approach hands you the wheel. Instead of the app routing your text through its own accounts and servers, you supply your own credentials for the model provider you trust. The app talks to that provider directly from your machine. There is no intermediary company sitting in the middle, collecting a copy on its way through. This matters more than it sounds. It removes the app vendor from the data path entirely. Your trust decision becomes a single, legible one: do you trust this model provider's stated terms, yes or no? You can read those terms. You can choose a provider whose terms you accept. You can switch. If you want a sense of the range of models available for this kind of work, the catalog of AI models shows how many distinct options exist, which is itself an argument for keeping the choice in the writer's hands rather than locking you to one vendor's pipeline. ### Route three: models that run on your own hardware The third approach is the most absolute. Open-weight language models can now run directly on a capable consumer machine. When the model runs locally, your text never crosses a network at all. The analysis happens inside the same box where the manuscript lives. The honest caveat: local models trade some capability for that total isolation, and they need reasonable hardware. They are improving quickly, and for many tasks, such as consistency checks, line-level feedback, and structural summaries, they are already useful. A flexible local-first app does not force one answer. It lets you pick per project, per chapter, even per question, where the privacy needs are highest. ### Why this is not a compromise Look at what those three routes share. In every one, the writer decides. Nothing is automatic. Nothing is ambient. Nothing happens to the manuscript that the writer did not initiate and could not inspect. That is the real shape of AI writing privacy done properly. It is not the absence of AI. It is AI as a tool you pick up deliberately, rather than a service that has been reading over your shoulder since you installed it. ### What the intelligence is actually for It helps to remember what you want the machine to do, because the best uses are diagnostic, not generative. You do not need a tool that writes your book. You need one that reads it the way a sharp developmental editor would and tells you where it sags, where a thread dropped, where a character's motivation quietly changed between chapter nine and chapter twenty. I have written elsewhere about how this works in practice, in the developmental edit nobody warns you about: the pacing charts, the continuity interrogation, the patient accounting of what the manuscript promises versus what it delivers. That kind of analysis is exactly the sort of thing that benefits from AI, and exactly the sort of thing you can do under the privacy conditions above. The value is in the reading. The reading does not require surrendering custody. ## Scrivener Cloud Alternatives and the Modern Workflow No honest essay on this subject gets to skip Scrivener. It earned its place. ### Why Scrivener won two decades of loyalty Scrivener became the default serious-novelist tool for good reasons. It stores your project locally. It organizes a long manuscript into manageable scenes and chapters. It lets you pin research beside your draft, rearrange structure without breaking it, and compile to a dozen output formats. Crucially, it never demanded that you live in someone's cloud. For a generation of writers, that local-file model was not a feature. It was the whole point, a tool that respected the idea that the book was yours. That loyalty is deserved, and nothing in this essay should be read as a dismissal of it. If Scrivener is working for you, you are not doing anything wrong. ### Where the workarounds start to strain But notice where the friction shows up. Scrivener's project format is a folder of many files, and its sync story has historically leaned on third-party storage services. That reintroduces the problem we met with Dolores: conflicted copies, sync collisions, and the quiet fact that your project folder now lives in someone else's cloud. Users who want the book on two machines end up managing a delicate ritual of closing, syncing, waiting, and reopening, all to avoid corrupting their own manuscript. A second strain is diagnostic. Scrivener is a superb organizer and a capable composition environment. It was not designed around the kind of continuous, structural analysis that modern assistance makes possible. A writer who wants to ask "where does my timeline contradict itself" or "which subplot did I abandon" is, in Scrivener, mostly on her own, armed with search and memory and good intentions. That is not a flaw so much as a boundary. The tool was built for a particular era of the writing process. ### What a local-first alternative actually adds If you are looking for Scrivener cloud alternatives, the useful question is not "which tool replaces Scrivener" but "which tool keeps what Scrivener got right and adds what it could not." That means three things. First, ownership stays structural. The manuscript lives on your drive, in an open format, with no required server in the loop. This is the thing worth preserving. Second, the syncing problem gets solved at the architecture level rather than bolted on. Because the app was designed local-first, it can reconcile changes deliberately instead of hoping a generic file-sync service guesses correctly. The conflicted-copy Sunday becomes a thing of the past. Third, intelligence is built in, under the privacy conditions described above. Planning, continuity, and diagnosis live inside the same tool as the draft, rather than in a dozen disconnected documents. That third point connects to something fiction writers feel acutely, which is the way outlines rot. A plan made in month one stops matching the book by month six. I wrote about the mechanics of that decay in the broken chapter four and why story bibles save it. A living story bible, one that stays attached to the manuscript and updates as the book changes, is precisely the kind of feature that works best when it sits inside a local-first app, close to the draft and safe from prying eyes. Your worldbuilding notes are as private as your prose, often more so. They deserve the same custody. ### Offline manuscript software is a category, not a limitation One last reframing. For years, "offline manuscript software" sounded like a polite way of saying "limited." It should not. The best software in this category is offline in the way a good fountain pen is offline: by design, as a feature, with the quiet confidence of a tool that does not need to ask permission. The limitation was never the offline part. It was the lack of ambition in the tools that happened to be offline. That ambition now exists. ## The Creative Custody Checklist The creative custody audit: testing five structural guarantees before trusting your manuscript to any software. Enough theory. Here is the practical part. Before you write word one in any tool, run it through five checks. I have kept them short on purpose, because a checklist you will not use is decoration. Ask yourself five questions. - Where does the canonical copy live? If the answer is "on the company's servers," stop and reconsider. The original should sit on your own drive. A cached view of someone else's database does not count. - Does it work with the network off? Pull the cable. Turn off the wifi. Open your project and write a paragraph. If the core experience breaks, the tool depends on a connection you do not control. - Can you open your book without the app? Check the file format. Plain text, Markdown, or a documented open database like SQLite means your work outlives the software. A proprietary blob means your work is held hostage to the vendor's survival. - What leaves your machine, when, and why? Demand a specific answer. Is anything transmitted in the background? Are crash reports scrubbed of content? When AI features run, exactly which text is sent, to which provider, under what retention and training terms? Vagueness here is itself the answer. - Who controls the exit? Can you export everything, completely, at any time, in a usable form, without asking? Can you delete your data and have deletion be real? A tool that makes leaving difficult is telling you something about who holds the power. Notice what these five have in common. Every one of them converts a vague worry into a testable fact. You are not asking whether a company seems trustworthy. You are asking what the architecture permits. Trust is a feeling. Architecture is a fact. ### How to apply it without becoming a full-time auditor You do not need to read source code. You need about twenty minutes. Read the privacy section of the documentation. Test offline behavior yourself. Look at the file format on disk. Send one support question asking exactly what is transmitted during AI features, and notice how clearly it is answered. A company confident in its architecture answers plainly. A company that is hedging, hedges. If a tool fails two or more of the five, I would not put a novel in it. If it fails one, ask whether the failure is something you can work around knowingly. If it passes all five, you have found something rare, and you can stop thinking about the plumbing and go back to the book. That, ultimately, is the point of the checklist. The goal is not vigilance. It is the end of vigilance. You do the audit once, carefully, and then you get to forget about it, because the structure of the tool is doing the protecting. If you are weighing options and want to see what a local-first setup with built-in assistance costs, the pricing page lays it out without a maze of tiers. ## The Desk as Sanctuary I started with a novelist who closed a tab and stopped writing for the night. I want to end with what she was protecting, because it is not a file. It is a condition. The condition under which a person can write the true thing. Fiction worth reading takes risks. It puts words in the mouths of people who say what we are afraid to say. It lets a narrator be petty, or cruel, or tender in a way that embarrasses the person who wrote it. It follows a character into rooms the author would never enter, and it does so convincingly enough that readers wonder, sometimes unkindly, how much of it is autobiography. All of that requires a writer who is not looking over her shoulder. Privacy is not paranoia. Say it again, because the accusation is common and it stings: privacy is not paranoia. A writer who insists on custody of her unfinished work is doing what a painter does when she keeps the studio door shut until the canvas is ready. Nobody calls that suspicious. They call it craft. The desk, in this sense, is not furniture. It is a promise: what happens here is mine until I say otherwise. Every writer who has ever produced something brave did it at some version of that desk, in some version of that quiet, with the particular freedom of knowing that nobody was reading yet. The software we choose either honors that promise or quietly breaks it. So choose the software that keeps it. Choose the local first novel writing app whose files sit on your drive, whose network is optional, whose intelligence is a tool you pick up on purpose and put down when you are done. Run the five checks. Read the terms once, carefully, and then never lose an evening to them again. And then write the draft about your mother. Write the cruel version. Write the unforgivable thought. Write it all, badly, bravely, without an audience, in a room that is finally, actually yours. Your manuscript never leaves the desk. Until you carry it out yourself. --- Source: https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s Markdown alternate: https://lacunai.com/blog/your-manuscript-never-leaves-the-desk-the-case-for-local-first-writing-s.md