Building MD+HTML Reader from a personal itch to a public macOS app
I did not build MD+HTML Reader because I wanted to make another Markdown app. It started with a small daily irritation. AI coding agents kept leaving useful documents inside my project folders: plans, implementation notes, release checklists, Mermaid diagrams, and HTML previews. The files mattered, but they were buried next to source code, configs, dependencies, and build output. Opening one file was easy. Reviewing the whole task was not. I kept switching between VS Code previews, browser tabs,
I did not build MD+HTML Reader because I wanted to make another Markdown app.
It started with a small daily irritation. AI coding agents kept leaving useful documents inside my project folders: plans, implementation notes, release checklists, Mermaid diagrams, and HTML previews. The files mattered, but they were buried next to source code, configs, dependencies, and build output.
Opening one file was easy. Reviewing the whole task was not.
I kept switching between VS Code previews, browser tabs, Finder, recent files, and random Markdown viewers. None of those tools were wrong. They just were not designed for the moment after an agent finishes a task and a human has to read the output.
That became the shape of MD+HTML Reader: a quiet Mac app for reviewing local Markdown and HTML files, not editing them.
I kept the product narrow
The app is not trying to replace VS Code, Obsidian, Typora, Finder, or the browser.
The workflow is much smaller:
open a local folder
-> filter Markdown and HTML
-> read rendered docs without editing source files
-> preview Mermaid and HTML artifacts
-> get back to recent work quickly
Enter fullscreen mode Exit fullscreen mode
That boundary helped a lot. As a solo builder, every extra promise turns into development, support, copywriting, screenshots, tests, and bugs. The first version had to be small enough to ship, but clear enough that a stranger could understand why it exists.
The public promise became simple: local-first reading for AI-generated Markdown and HTML inside project folders.
The app working was only the first step
The first version was useful to me once it could open folders, filter docs, render Markdown, show Mermaid diagrams, preview HTML, and remember recent documents.
But a public product needs more than the main feature.
I still had to build the path around it:
- a product page that explains the pain in plain English;
- pricing that makes the trial, monthly plan, and lifetime option easy to understand;
- privacy and terms pages that explain local document handling;
- Creem checkout and license activation;
- app and website analytics that avoid local file names and document content;
- signed and notarized macOS builds;
- a DMG, updater files, release notes, and live download checks;
- screenshots, demo assets, launch copy, and blog posts.
That was the uncomfortable lesson: “it works on my machine” is not a product. It becomes a product when someone else can find it, download it, trust it, pay for it, and update it without me sitting beside them.
Payment was more than a checkout link
I chose a self-serve path: free trial first, then a low-priced monthly plan or lifetime access. The goal was not perfect pricing. The goal was to learn whether anyone would pay for this workflow at all.
The payment work had more pieces than I expected:
- checkout links;
- license key activation inside the app;
- backend license validation;
- local entitlement state;
- expired and invalid license states;
- test and live environments;
- support copy for the wrong email or a missing key.
The product rule was clear: a paid user should not need me to manually unlock the app. If every purchase creates manual work, the product is not shaped correctly.
Analytics had to stay boring
MD+HTML Reader is local-first, so analytics had to be boring on purpose.
On the website, I care about visits, downloads, pricing views, checkout clicks, and source attribution. In the app, I care about opens, daily activity, trial locks, checkout clicks, license activation, and invite actions.
I do not want local paths, file names, or document content in analytics. That boundary is part of the product, not just a privacy sentence.
It also changes how I look at traffic. A spike is not enough. I need to know whether people downloaded, opened the app, returned, clicked pricing, and activated a license.
macOS release work is a product of its own
Shipping a macOS app publicly is a separate project.
The app has to run on Apple Silicon and Intel Macs. It needs Developer ID signing. The DMG needs notarization. Gatekeeper has to accept the downloaded file. Auto-update needs a signed archive, a signature, and a live latest.json manifest.
I also learned that release notes are part of the product. If the app shows an update prompt, that sentence should be short, clear, and checked before packaging.
The release flow became a repeatable path:
bump version
-> build signed app
-> notarize and staple
-> generate DMG and updater files
-> build website download assets
-> deploy
-> verify the live page, download, latest.json, hashes, and updater checks
Enter fullscreen mode Exit fullscreen mode
It is repetitive, but that is why it is useful. Every release should make the next release safer.
Promotion forced better wording
Promotion is not just “posting after launch.”
The product page, screenshots, demo video, Product Hunt copy, Show HN post, Reddit angle, directory listing, and SEO post all ask the same question:
Can a stranger understand why this exists?
Enter fullscreen mode Exit fullscreen mode
“A Markdown and HTML reader” is too broad.
The clearer angle is:
Review AI-generated Markdown and HTML without code-file clutter.
Enter fullscreen mode Exit fullscreen mode
That sentence says who it is for and when it helps.
What I want to reuse
The most useful part of MD+HTML Reader may be the system left around it.
For the next product, I do not want to start from zero. I want to reuse the product page structure, pricing and license flow, analytics events, release scripts, launch checklist, promo asset structure, and blog format.
That is the bigger lesson for me: one small product should leave behind infrastructure, language, and distribution learning for the next one.
Where the bet stands
MD+HTML Reader is still early. I am not writing this as a victory lap.
The bet is simple: AI agents will keep creating local project documents, and people will still need a calm way to review them.
If that is wrong, the product should teach me quickly. If it is right, the same product system can support the next app with less manual work.
That is the kind of indie product I want to build: small, useful, and able to make the next product easier.
MD+HTML Reader is available here: MD+HTML Reader.
