Devlog 004: The Part Where Everything Gets Complicated

Hello again, writers!

Remember when I said Draftmount was starting to look like a proper writing application? Apparently that was my cue to find everything that needed fixing.

Most of September went into the less glamorous parts of development: the things you never notice when software works and can’t ignore when it doesn’t. There have been some interesting discoveries.

Time to actually use the thing

It’s one thing to type a few paragraphs and declare an editor functional. It’s another to work across several chapters, jump between scenes, reorganize a project and expect everything to hold together. So I put Draftmount through longer, more realistic writing sessions.

Some interactions that seemed reasonable during development turned out to be surprisingly irritating an hour into a session: an extra click to reach something I needed often, a menu that took too long to open, a panel that sat in the way while I was trying to concentrate. Small things add up, and fixing them as I went has made the workspace much more comfortable.

Manuscripts are complicated creatures

Writers have a remarkable talent for turning a tidy manuscript into chaos. I say this with affection, because I am one of them.

I tested how Draftmount handles larger projects as chapters and scenes multiply. Moving sections around should feel natural, finding a particular scene shouldn’t require a treasure map, and the structure has to stay readable even when a project gets ambitious. More than once I solved a navigation problem only to discover I’d created a different one. Software development is humbling like that.

Exports deserve some love

Exporting sounds simple until you think about formatting, chapter structure, headings and all the small details writers expect to survive the trip. The goal is to make it easy to take your work elsewhere whenever you need to. I’m still testing how each format should behave, especially with more complicated manuscripts.

A growing list of little fixes

I reviewed spacing, keyboard interactions, navigation, and how different parts of the app respond to changes. Some fixes were refreshingly simple. Others involved staring at a file for an unreasonable amount of time before discovering the cause was something embarrassingly small.

I would love to say that only happened once. It did not.

Thinking about the people who will use Draftmount

I want to introduce Draftmount gradually, to a small group who can spend real time with it and tell me where things feel confusing or unreliable. That means planning onboarding, feedback and documentation, and working out how to explain features that are still in progress.

I also want to be clear about storage during the early testing stages. Writers should know exactly how their manuscripts are saved and what precautions to take. Software earns trust through how it behaves.

Four months already?

It’s funny how quickly a little project becomes the thing you think about while making coffee, eating dinner or trying to fall asleep. I’m learning a lot about choosing which problems deserve attention first, because there’s always another feature to start or another detail to polish. For now, the foundations come first, and I’m trying to spend slightly less time arguing with my own code.

What’s coming in October?

October is about preparing for a fuller round of testing: the writing workflows, the reliability of saving and exporting, and making sure the interface makes sense to someone who hasn’t been staring at it for months. I’ll also start pulling together what writers need to know before they try Draftmount.

We’re getting closer. I’m a little terrified, but mostly excited. Thank you for following along.

Until the next draft,

The Draftmount Developer