My wife decided to get back to writing, and I thought I could make her a small Mac app. I had a fairly ordinary picture in my head: the manuscript in the middle, some story memory nearby, a little AI help for notes and continuity, and nothing changing unless the writer accepted it. I gave myself about a week.
That estimate lasted until I started asking what “nearby” meant. A character note is not very useful if it lives in a separate database that has to be maintained like a second job. A generated suggestion is not safe just because it sounds good. A chapter summary that reads well in English can still be incomplete for a Chinese manuscript, and a model can have plenty of context while quietly following an old version of the story. The simple app became a set of small questions that all had consequences for the writing experience.
The first surprise was that the hard part was not generating text. Calling a model is relatively easy. The difficult part is deciding what the model is allowed to see, what the application should remember, and what must remain untouched until the writer makes a decision. The product needed a manuscript, but it also needed a boundary around the manuscript. Those are different things. The draft is the source of truth; the planning notes, extracted candidates, observations, and suggestions are supporting material.
That distinction affected the interface. I did not want to build another assistant dashboard with a text area in the middle. When someone is writing a novel, the novel has to remain the most important object on screen. Story Memory should help the writer return to the work, not pull them away into a collection of panels. The more features I added, the more often I had to remove or move something because it was becoming the centre of attention.
It also affected persistence. A writing app cannot treat a manuscript as temporary UI state and hope to save it later. Chapters, plans, memory, annotations, and snapshots need clear ownership on the Mac. Provider credentials need a different boundary again, because an API key is not ordinary project data. The application has to be useful without a cloud manuscript, while still allowing a writer to choose where model inference happens. Local-first turned out to be less about promising that every computation happens on the device and more about making sure the book belongs to the writer’s workspace.
The first version taught me that a writing tool has to be quiet about its intelligence. The writer should be able to write without constantly being asked to classify, confirm, configure, or explain the book. AI can prepare a useful proposal, but it should not become another source of maintenance. Story Memory needs to be visible enough to review and quiet enough not to interrupt every sentence.
The estimate also failed because I was thinking about screens instead of habits. It is easy to picture a button called “extract memory” or a panel called “continuity.” It is harder to imagine the writer coming back three days later, opening a chapter, remembering why a decision was made, and deciding whether the application has actually reduced the work. A feature is not finished when it has a place in the interface. It is finished when it behaves well in the ordinary moments around writing: reopening a book, changing a chapter, undoing a mistake, or ignoring a suggestion without being punished for it.
That perspective changed the order of the work. Instead of asking what else the app could display, I started asking what it should refuse to do. It should not overwrite the manuscript because a model returned a polished answer. It should not make a writer maintain a second canon database by hand. It should not turn a temporary provider failure into a locked project. It should not hide the local files behind an account requirement. Those refusals are less impressive in a demo, but they are what make a writing tool trustworthy after the novelty has worn off.
There were also very ordinary Mac problems. Text input is not just a stream of English characters. Chinese and Japanese composition, Arabic direction, selections, undo, formatting, and cursor behavior all belong to the operating system’s text stack. A custom shortcut or a full-string comparison can look harmless in a demo and become painful as soon as a real person types. The right answer was often to use more of the native system and less of my own cleverness.
That has been the recurring pattern. Every time I thought I was adding a feature, I found a boundary I needed to respect first. Formatting should not change the plain manuscript or enter the extraction pipeline. A trial limit should not delete saved provider settings. An old paid customer should not lose access because the business model changed. A background job should not project a stale answer into a book that has moved on.
WolfeWriter is now in the Mac App Store, and it is much more than the one-week app I imagined. It is also still early. The useful part of the original idea survived, though: keep the manuscript central, keep the book’s context close, and make every intelligent change reviewable. The rabbit hole was not a detour from that idea. It was the part that revealed what the idea actually required.
The novel writing app guide describes the current workflow in more practical terms. This journal will stay closer to the decisions and mistakes behind it.
