I built a native Mac Markdown editor solo, with zero dependencies. It launched on Product Hunt today

Pedro “PT” Thomaz — Wed, 11 Nov 2026 00:31:37 +0000

Hi DEV! I'm Pedro, and for the past months I've been building Coffee, a Markdown editor for the Mac, on my own. It went live on Product Hunt today, so here's what it is and a few things I learned building it.

What it does

Plain files. Every note is a .md file in a folder you choose. No database for your writing, no import step, and any other editor can open the same folder (an Obsidian vault works as it is).
Answers beside the line. Write 20% of 50, $30 in EUR, Tokyo time or half of 175 and the answer appears next to the line, without going into your file.
Maths and Mermaid, drawn natively. No web view: TeX and Mermaid diagrams are rendered by the app itself.
Review every AI edit. When Claude, Cursor or anything else changes a note's file, Coffee lays out every change and you keep or undo each one.
MCP, off by default. AI apps can read and write your notes over MCP, but only once you turn it on.

How it's built

Swift 6.2 and SwiftPM, macOS 15 and later.
Zero third-party dependencies. The Markdown parser, the Mermaid and TeX renderers and the calculator are all written for the app. Search runs on the system's SQLite.
Separate small executables for the MCP server, Quick Look and the updater, so each one does one job.

Writing my own Mermaid renderer sounded like a bad idea at first, but it means diagrams appear instantly, look like the rest of the app and work offline.

What I learned on launch day

The launches above mine came in with three to five times more Product Hunt followers than I had. Followers before the day matter far more than anything you do on the day. If you're planning a launch, start collecting them weeks earlier.

Try it

14 days free, no card or account: coffeetext.app

It's in its final hours on Product Hunt, and I'd love honest feedback there or here: Coffee on Product Hunt

What would make you switch from your current Markdown editor?

Why I shipped rules and statistics instead of an LLM for my health app

Pedro “PT” Thomaz — Sun, 16 Aug 2026 09:57:44 +0000

I build Vitra, a desktop app that reads your Oura Ring data and gives you one plain sentence each morning about how your body is doing. The obvious way to build that in 2026 is to pipe the numbers into an LLM. I went a different way, and I think the reasoning generalises past health apps.

The problem with the LLM version

Exporting a month of JSON into a chat window every morning is a chore, but that is a UX problem and UX problems are solvable.

The harder problem is stability. Push back on a recommendation and the model tends to fold and tell you the opposite. Same numbers, same night of sleep, different advice, because you argued.

That is fatal for this particular product. If the app says take a rest day, the entire value is that it holds that position when you do not want to hear it. An opinion you can talk the model out of in one message is a mirror with extra steps.

This is sycophancy. It is well documented, and it is not something you fix with a system prompt telling the model to be firm. You can reduce it. You cannot make it deterministic.

What I shipped instead

Transparent rules and statistics computed over the user's own history:

Establish a personal baseline per metric over the first one to two weeks, rather than comparing against a population average
Detect deviations from that baseline, not from a global "normal"
Require multi-day agreement before making a confident call, so one bad night does not trigger anything
Encode the decision thresholds explicitly, before the app has seen today's data

That last point is the one that matters. The rule is committed to in advance, today's numbers get evaluated against it, and the user arguing does not change the arithmetic.

What that buys you

Determinism. Same inputs, same output, every time. You can write tests. With a model in that position, "did it give the right answer" is a vibes check.

Explainability. When it says recovery is trending down it can point at which signals moved and by how much. That is the actual computation, not a post-hoc rationalisation.

Regulatory headroom. Under EU MDR Rule 11, software intended to inform a diagnostic or therapeutic decision starts at Class IIa. A wellness app has to stay clearly on one side of that line, and it is much easier to argue about a rule you can print out than about a model's output distribution.

It runs locally. No inference API calls means no account and no server doing the analysis, and health data that never leaves the machine. To be precise, since people ask: the licence check does talk to a server when you activate a key, and that is the only call that leaves. It carries no health data. This was the deciding factor. Local-first with a frontier model in the loop was not going to happen, and the privacy story turned out to be what people actually cared about.

The part I underrated: you can correct it

A fixed rule is a thing you can teach. If Vitra blames your late workout for a bad night and that is wrong for you, you say so, and the correction sticks. Your thresholds drift toward you over time instead of sitting at the average of everyone.

Determinism is what makes that possible. Something that rerolls its own reasoning every morning has nothing stable to correct, so there is nothing to teach.

Worth being precise about what determinism means here. Same inputs give the same output, and your corrections are part of the inputs. The sentence can change over time, and when it does you can point at exactly which correction moved it.

Where a language model still earns its place

I am not arguing against LLMs. I am arguing against putting one on the critical path of a decision that has to be stable.

Phrasing is a good use. Turning a computed result into a sentence that sounds human is exactly what these models are good at, and if that layer is sycophantic the worst case is slightly awkward wording. Freeform Q&A over your own history is another. Both sit downstream of the judgement rather than being the judgement.

The heuristic I ended up with: if you would be upset by the system changing its answer because the user pushed back, do not put a language model in that position.

Caveats

Rules do not generalise for free. Every new signal is real work, and a threshold that looks sensible on paper can turn out to be noise once it meets real data. A model would have "handled" those cases immediately, just not necessarily correctly, and you would not know which ones.

There is also a real product cost. The app stays deliberately quiet for the first couple of weeks while it learns your baseline, which is a strange thing to ship when every competitor tries to impress you on day one. I still think it is the right call.

Here is what it actually looks like in the morning:

Vitra is at https://vitrahealth.app if you want to see what it turned into. Mac and Windows, one-time purchase, no subscription.

Happy to be argued with, especially by anyone who has made the sycophancy problem tractable in production.

DEV Community: Pedro “PT” Thomaz