Moth started because I was tired of looking at Markdown files in Notepad.
That is the entire origin story.
My AI workflows increasingly produced Markdown by default, particularly inside larger project folders where plain text was fast for the model to read and easy to pass between different steps.
Technically, this was fine.
Visually, it was not.
I was spending a lot of time reading drafts, notes, reports and project files in a format that looked like something I should be debugging rather than reading.
I looked at Obsidian.
It was far more than I needed.
Then I looked for a simple Markdown reader that felt calm, readable and vaguely bookish.
I found a few.
I did not like looking at any of them.
So I opened Claude Code and typed:
Hello, can you make me a pretty MD reader? I currently open MDs in notepad and it's just not pleasing to the eye, I'd like something more bookish with cream paper.
That was the specification.
The original requirement lasted about three minutes
The first version was just a reader.
Then I immediately realised that if I already had the file open, it would be useful to edit it too.
So Moth became an editor.
Then I realised that if it was going to be an editor, I needed to be able to create a new file.
Then Save As.
Then search.
Then a few font choices.
Then colour schemes.
Then export to PDF.
Then EPUB, because I thought authors might find that useful.
This is more or less how software projects happen when nobody is making me write a formal requirements document first.
The important part was that none of these additions felt expensive.
I could use the tool, find a friction point, say what annoyed me, and have the application adjusted.
Why Markdown in the first place?
I did not adopt Markdown because I was particularly enthusiastic about Markdown.
The language models were.
It had become a convenient working format inside my AI workflows because it was plain, structured and quick to read.
I could have asked the models to produce Word documents instead, but in practice those often felt slower and heavier to extract information from.
Markdown worked beautifully for the machine.
I just wanted it to work beautifully for me too.
Moth became the layer between those two needs.
The AI could continue using the simple file format it preferred.
I could stop staring at it in Notepad.
Everybody wins.
The aesthetic requirement was not optional
The main problem I was solving was not technical.
It was aesthetic.
I wanted cream paper.
I wanted something that felt quiet and pleasant to read.
I wanted to open a draft and feel like I was reading a document rather than inspecting a file.
The first version actually looked pretty good.
Codex and I disagreed slightly on what counted as visually pleasing, so there were some adjustments.
A dark bar across the top did not survive.
A few colour combinations were politely removed.
I added several themes and font options.
Nothing dramatic.
But the entire project existed because I cared about how the software felt, so “technically functional” was never going to be enough.
I did not write any of the code
I directed the build conversationally.
That was my entire development interface.
I described what I wanted.
I ran the result.
I pointed out what I disliked.
I asked for features.
Codex changed the software.
I did not choose the framework.
I did not know what toolchain was required to package it.
When Rust, Cargo and Microsoft build tools entered the conversation, I mostly accepted that these were apparently things the computer needed in order to turn my pretty Markdown reader into an actual Windows application.
I did not need to understand them deeply enough to build Moth myself.
That distinction matters.
AI did not magically make software development cease to exist.
It changed which parts of software development I personally needed to care about.
From browser toy to real application
The earliest version opened in a browser.
That proved the idea, but it was not yet the thing I actually wanted.
I wanted to be able to open a Markdown file with Moth the same way I would open a document with any other desktop application.
So it became a proper packaged app.
Again, I did not begin the project knowing whether that would be difficult.
The experiment was partly:
Can I actually make this?
Apparently, yes.
A surprisingly short path to usable software
The first genuinely usable version took roughly half an hour.
Not the finished version.
Not every feature.
But enough that I could open Markdown in something I preferred to Notepad.
After that, the application improved through use.
I would work with it, notice something missing, and add it.
Search came from using it.
New-file creation came from using it.
Save As came from using it.
Those were not speculative roadmap features.
They were annoyances.
That became the development loop:
use → get irritated → ask for fix → continue using
It was an extremely effective product-management methodology for a user base of one.
Some features were for hypothetical future users
PDF and EPUB export were different.
I did not personally need them.
Once I realised there was surprisingly little available in the category of “simple, nice-looking Markdown reader,” I started wondering whether other people might like Moth too.
So I added a few features that would make it more generally useful.
PDF export worked normally in testing, although the browser-based version inherited Chrome’s tendency to add things like URLs and date stamps unless the user changes the print setting.
That was less a Moth problem than a browser problem, and it disappears once the application is properly packaged.
EPUB export was partly practical and partly curiosity.
If authors were going to use the tool, perhaps it would be useful.
The files worked.
I have not reorganised my life around EPUB export since.
That is fine.
Not every feature has to become a revelation.
Moth does not contain AI
This is one of the things I like most about it as an AI project.
There is no chatbot inside Moth.
There is no summarisation button.
It does not rewrite your prose.
It does not upload your files somewhere to run inference.
It is a conventional local application.
AI was used to build it.
That feels increasingly important.
A lot of discussion around AI products assumes the AI has to appear inside the finished product.
Moth is a different kind of example.
The intelligence was in the development process.
The finished software can remain simple.
Local first because there was no reason not to be
Moth stores and opens ordinary local files.
There was no need to invent a cloud account, sync layer or subscription.
A Markdown reader does not inherently need access to the internet.
My documents do not become more readable because they have travelled through a server first.
So they stay on the machine.
That was not a grand privacy architecture.
It was simply the obvious design decision.
Sometimes software can just open a file.
The interesting part is not Moth
Moth is useful.
I still use it regularly.
But the more interesting thing is what I would have done before coding agents existed.
Nothing.
I would not have hired a developer to make me a Markdown reader.
I would not have spent weeks learning enough programming to build one.
I probably would not even have paid much for an existing one, because the problem was too small.
I would have opened the file in Notepad and accepted that this was mildly annoying.
That is what changed.
The cost of custom software used to mean the problem had to be large enough to justify solving.
Coding agents lower that threshold dramatically.
Now the question can simply be:
Would I like this to exist?
And if the answer is yes, sometimes that is enough.
Software for one person
Moth made me start thinking differently about personal software.
There are countless tiny problems that are not large enough to become products.
A tracker designed around one household.
A dashboard for one peculiar workflow.
A reader that looks exactly the way one person wants it to look.
A utility that saves three annoying clicks in a process nobody else on earth performs the same way.
Historically, those problems were too small.
You adapted yourself to whatever general-purpose software existed.
Now it is increasingly reasonable to adapt the software to yourself.
That feels like a bigger shift than “people can code with AI.”
The interesting possibility is that software no longer has to serve a market before it can justify existing.
It may only need to serve a person.
And that may eventually become a problem for big software
I do not think general-purpose software is disappearing tomorrow.
But I do think personalised software changes the competitive landscape.
Large software products inevitably accumulate compromises because they have to work for millions of people.
The more capable coding agents become, the easier it becomes to ask:
Why am I adapting my workflow to this application when I could build an application around my workflow?
Most people are not going to replace every major platform with something they generated on Tuesday afternoon.
But for small, specialised tasks?
That threshold has already moved.
Moth exists because I thought Notepad was ugly.
That would once have been nowhere near enough reason to build software.
Now it was.