Local-First Markdown Editing

Local-first starts with a real file you control

A local-first Markdown workflow treats the file on your computer as the source of truth. The document is not trapped inside a private database, a browser session, or a hosted workspace that only one product can read.

That matters because Markdown is supposed to be boring in the best way. You can copy a .md file to another folder, put it in Git, search it with normal tools, attach it to an issue, or open it in a different editor years later.

# Launch Notes

## Decision

Keep the Markdown source in the project folder.

## Why

- The file can be backed up
- The team can review it later
- Another editor can still open it

## Next

Save a local copy before publishing.

Use the browser for speed, desktop for durable work

The browser is the right place to test an idea quickly. Paste Markdown, check the preview, export HTML, or download a copy without signing in. That low-friction start fits documents you may not keep.

The desktop app becomes the better home when the draft turns into a real file: a README, a runbook, class notes, meeting notes, a product spec, or a blog draft you will revise more than once. Native open and save, offline access, recent files, and local history are the difference between a quick tool and a daily writing workspace.

Local history is part of document safety

Undo is not enough for real writing. A mistake may be saved, the app may be reopened later, or a large paste may change a long document in a way that is hard to inspect. Local history gives the editor a safety net that is closer to how people actually work.

VeloWrite keeps basic local history in the free preview. Accidental recovery should not be treated as a luxury feature.

The rule needs to be easy to understand: how many snapshots are kept, what happens when the limit is reached, and how to protect important files outside the app.

# Draft Review

## Before editing

Keep the current argument short.

## After editing

Expand only the examples that support the main point.

## Recovery rule

If the edit gets worse, compare with the previous saved version before restoring.

Sync should preserve folder ownership

A good sync layer should not make local files feel less local. The folder should remain visible, backup-friendly, and usable in other tools. Sync should move changes between devices, not turn a Markdown vault into an opaque account-only workspace.

Many users already have a sync habit: Git for project docs, Syncthing for private machines, iCloud or OneDrive for everyday files, Dropbox for shared folders. VeloWrite should respect those choices before introducing anything heavier.

The most useful near-term work is not a hosted sync service. It is predictable file behavior: clear save paths, recent files, import/export, conflict explanation, and documentation that tells users what is stored locally.

# Notes Folder

## Structure

- `inbox.md`
- `project-plan.md`
- `meeting-notes.md`
- `archive/`

## Sync rule

Keep the folder visible so another backup or sync tool can protect it.

Recovery rules need to be visible

History and sync overlap. If two devices edit the same file, the editor should help users see which version changed, when it changed, and what can be restored. Silent overwrites are worse than asking the user to make a choice.

Before VeloWrite adds any advanced sync behavior, it should document the basic recovery model: where snapshots live, how restore works, whether deleted snapshots can be recovered, and what users should back up themselves.

This is part of the everyday editor. Clear recovery rules reduce support questions and make the desktop app safer for daily documents.

A practical local-first Markdown workflow

Start in the web editor when the document is only an idea. Move to desktop once the file deserves a name and a folder. Keep important documents in a project folder, a synced folder you control, or a Git repository if version history matters.

Use preview while drafting, export only when the document is ready to share, and treat local history as a recovery layer rather than your only backup. That keeps the workflow lightweight without pretending the editor should own everything.

Continue with VeloWrite

Download Desktop

View Roadmap