Off-the-shelf editors trade away one of three things: portability, control, or quality.

A markdown editor usually asks for one concession. A heavy desktop install, or documents that live on someone else's service, or markdown treated as a side-show beside a richer editor. Email-template tools ask for a different one. The author writes against their renderer and their font catalogue, then trusts a preview that is only roughly what the recipient will get, wrong often enough to matter.

mark-one refuses both trades. It is a markdown editor first, an email-template authoring client second, and its data lives on the operator's own Cloudflare account. A single writing surface that is the same everywhere, depending on no third-party service to keep working.

mark-one authors and renders. It never sends.

A finished template is rendered, never delivered here. Each save appends an immutable version row and moves the live pointer to it, so a later send binds to a specific snapshot and never drifts. When the email needs to go out, mark-one hands the finished pair to the separate ae-mail system over a private worker-to-worker binding. ae-mail owns the audience, the suppression list, and the send. The seam carries a typed contract and nothing more.

Authors here, delivers there mark-one
01 Editor
markdown core, live preview, multi-format export
02 Versions
append-only snapshots, a moving current pointer
03 Renderer
the pure pipeline that produces { html, text }
04 Brand
a typed eight-slot palette, no freeform colour
05 Delivery
the actual send, owned end to end
06 Audience
recipients, segments, opaque references only
07 Suppression
who must not be mailed

The preview pane and the production send are the same pipeline.

The whole email pipeline is pure TypeScript: a markdown walker that consumes an eight-slot brand palette, a CSS inliner, and a plaintext mirror for the multipart fallback. That pipeline runs in the editor on every keystroke and on the server at render time. One source feeds both. The preview is not an approximation of the send. It is the send, drawn early.

One source, one renderer mark-one
Markdown body one source · brand + variables
Editor preview · on every keystroke
01 Walk
markdown to inline-styled, table-based HTML
02 Palette
resolve brand to its eight colour slots
03 Inline
inline every style, conditional fallbacks for strict clients
04 Mirror
plaintext fallback for the multipart pair
Production render · at send time
01 Walk
the identical pipeline, no second implementation
02 Palette
the same eight slots, resolved by value not by id
03 Inline
the same inliner
04 Mirror
the same plaintext mirror
{ html, text } byte-identical across both tracks

A markdown-first authoring surface, owned end to end.

What the writer gets: a portable editor whose preview is the send, versioned templates, a typed brand, and a clean handoff to delivery.

What it gives you mark-one
Editor
A markdown editor first, an email client second.
Live preview
The preview runs the production renderer.
Versioned
Every save an immutable snapshot.
Multi-format
The multipart pair: HTML and a plaintext mirror.
Self-owned
Data on the operator's own Cloudflare account.
Brand palette
8 Typed slots. Colour cannot drift.
Hands off
Passes the pair to ae-mail. Never sends.

The draft is the inbox.

The brand a template binds to is a complete palette consumed whole, so blockquote text, inline code on its subtle surface, and links over the accent bar cannot drift out of harmony between the editor chrome and the recipient's client. With one renderer behind both surfaces, the preview pane stops being a best guess at the send. The author reads the finished email in the pane, and the recipient reads the same bytes in the inbox.

The gap closed mark-one
Without it
Two renderers drift, and the preview is a guess at what the recipient gets.
With mark-one
One renderer behind both, so the draft on screen is the email in the inbox.
work