Identifying distraction
I wanted to write every night, and I kept not doing it. When I paid attention to what I was actually doing at the keyboard, the answer was uncomfortable: I was reaching for the mouse more often than I was putting prose on the page.
Microsoft Word’s ribbon makes sense for someone laying out a document. For someone trying to draft a chapter, every control on it is an invitation to stop writing and start adjusting: a font, a heading style, a margin. The friction wasn’t in the writing. It was in the behavior the tool encouraged.
Scrivener goes the other way. It’s built for managing a manuscript, with a binder, corkboard, and compile settings, and even in its full-screen mode it’s never far from the organizing tools. It’s powerful, but it asks you to run a project when all I wanted was to write the next sentence.
The apps closest to what I wanted were minimal editors like Typora and Sublime Text, which I pointed to when I started.
Removing distraction
The first thing I wrote down was the goal: a lightweight app with minimal distractions, optimized for the experience of writing. As the build went on I sharpened it into one sentence: a place to write prose, novel-length, without distraction, saved as plain Markdown. Every decision was checked against that sentence, and most features failed it.
The look came after the first working build. It was a perfectly good editor, but a generic one, and it didn’t feel calm. I asked what it would look like styled like an e-ink display, and that question set the direction.
The reference was Amazon’s Kindle and the reMarkable: screens you read for hours without noticing them. That became a near-grayscale palette of warm paper, near-black ink, and a faint grain you feel more than see. Color went away entirely, so links and list markers are carried by weight and underline instead. Nothing on the page competes with the words.
AI as the means of production
I’m a designer, not an engineer. I didn’t hand-write Calliope’s code. I built it by directing Claude Code, an AI coding agent working in the terminal, across five working sessions. It wrote the Electron and CodeMirror code, then ran the app, took screenshots, and checked its own work before handing it back. My job was the rest of it: the product and design decisions, visual direction, and testing the real build.
The loop was fast. I’d describe what I wanted, sometimes with nothing more than a screenshot of another app (“what if we style the sidebar similar to this?”). The agent built it and showed me proof. Then I rebuilt the app and used it. Most of my roughly 170 messages were reactions, not specifications: the pill’s content sits too close to the middle, the traffic lights don’t look vertically centred, this looks unpolished.
It worked best when it was a real conversation, not a chain of commands. The agent pushed back when it disagreed, and some of its pushback made the product better:
- I suggested a first-run screen for choosing where pages are saved. The agent argued that it added friction before the first word, and it was right. Pages save to a default location, and “Change Pages Location…” sits in the File menu.
- I wanted smart quotes and dashes, then asked whether they’d hurt the Markdown. The agent agreed they would if they rewrote the file, so we made them change only what’s on screen.
It went the other way just as often:
- The agent proposed a Scrivener-style Compile feature. I said it worked against the whole idea of distraction-free writing, and we dropped it.
- The agent grouped the scratchpad with the view modes. I pointed out it’s a place you go, not a way of seeing the page, so it moved to the navigation rail next to the pages.
- The theme button seemed to need two clicks. The agent’s fix quietly made one theme unreachable. I suggested a small dot on the moon icon to show when “auto” is on. That was simpler, and the agent reverted its fix for it.
When I wasn’t sure about a technical call, I got a second opinion. A paragraph-indent feature kept failing to render reliably. Before letting the agent try a third approach, I checked its diagnosis with Gemini. Both agreed on the cause, so we cut the feature instead of fighting the editor.
Decisions I'd defend
- Markdown instead of a formatting toolbar
- A toolbar invites you to stop writing and start formatting. With Markdown, formatting stays on the keyboard, in the same flow as the words.
- No Compile feature
- Scrivener's Compile is powerful, but it's a whole second product. Per-page export gets writing out of the app without adding a setup screen.
- Smart typography only on screen
- Curly quotes and dashes appear on screen, but the saved file keeps exactly what you typed. The writing stays plain and portable.
- No first-run setup
- Pages save to a sensible default location from the first keystroke. You can move them any time from the File menu.
- Typewriter scrolling is always on
- Making it a setting would have added a setting. Keeping the current line centred is simply how the page behaves.
Most of the design was saying no
With an agent that could build almost anything in minutes, the risk flipped. The limit was never whether we could add something. It was whether we should. Speed made restraint the actual design skill.
A competitor, CalmlyWriter, uses a floating toolbar that inserts Markdown when you click. I brought it up, and we talked it through. A toolbar would make Calliope’s Markdown guide pointless, because the guide exists so you can learn the syntax once and then just type. That’s a different product. The toolbar stayed out.
The same test decided everything else. We kept features that solve a real problem for someone writing a long manuscript:
- Search across all pages, to find the line where a character first appears.
- Undo for the last deleted page, rather than a full version history.
- Spellcheck, which was quietly switched off in the editor library and had to be turned back on.
Features that turned the app into a place to manage writing, instead of a place to do it, were left out.
Even the chrome got this treatment. The Markdown guide first slid up over the page list. I’d seen a narrow icon rail in another editor, Ghostwriter, and suggested it instead. That way, switching to the guide or search never shrinks the list of pages. Over several passes I moved controls to where they belong: things that change how you see the page (Hyperfocus, syntax, word count) stay in the footer, while destinations and the theme go on the rail.
Keeping the writer’s eyes in one place

Hyperfocus mode dims every line except the one you’re on, and within that line every sentence except the one you’re writing. The first version sat alongside an ordinary paragraph focus mode and an optional typewriter-scrolling setting. I asked what typewriter scrolling actually did, then cut it down: typewriter scrolling became always on, the paragraph mode went away, and Hyperfocus took its shortcut. One mode, no settings.
Always-on scrolling brought the most interesting bug of the project. Clicking into the text randomly highlighted words. I found it by using the app and sent a screenshot. It turned out the page was re-centring while the mouse button was still down, so the text moved under the pointer and the app treated it as a drag. The fix pauses centring until the button is released. It’s a small detail, but details like that decide whether a writer trusts a tool.
Markdown hides itself. Syntax like ** and # only appears on the line the
cursor is on. Everywhere else the page reads as finished text. My one addition
was a single </> toggle for anyone who wants to see all the syntax at once.
What shipped
Version 0.1.0 shipped as a macOS app:
- An e-ink theme, a dark theme, and an automatic mode that follows the system.
- Markdown that hides its own syntax, and smart typography that only changes the display.
- Always-on typewriter scrolling and Hyperfocus mode.
- Pages stored as plain
.mdfiles in a folder you can move, with import and export. - A scratchpad kept out of the page list and word counts, search across every page, and undo for the last deleted page.
- “Created by” credits in the About panel. There’s also a hidden “Oceanic” theme for anyone who goes looking.
What I’d do differently
I’d make the agent test the way I use the app. The hidden theme was meant to unlock with a right-click on the moon icon. The agent reported it as verified several times, but its automated tests clicked differently than my mouse did. The real app kept doing the wrong thing, and it took several rounds of “still the same” before we dropped mouse tricks for a plain keyboard shortcut. A passing test is not the same as a working feature, and I should have asked sooner how the agent was testing.
I’d put it in front of other writers sooner. Every decision here has been checked against one writer: me. That was the right way to find my own friction. But before adding anything else, the next step is watching a few other people draft a chapter in it.