I Shipped a Privacy-First Markdown Converter in 3 Days. Here’s What the Launch Post Usually Leaves Out

Most launch posts follow the same script:

I had an idea, built it quickly with AI, shipped it, and here is the feature list.

That is the clean version.

The useful version includes the wrong assumptions, the features that were deliberately cut, the conversions that looked correct until I opened the downloaded file, and the uncomfortable fact that “works on my machine” is not the same as “works for a stranger.”

So this is the useful version.

I built MDFold, a free set of browser-based tools for moving documents into and out of Markdown. The first working version took three days. It now handles eight practical workflows:

• PDF to Markdown
• Markdown to PDF
• Markdown to Word
• Word to Markdown
• Markdown to HTML
• HTML to Markdown
• Markdown to PNG or JPG
• Visual and CSV-based Markdown table generation

No account is required, and the conversion work happens in the browser.

But those bullet points are the least interesting part of the story.

The original idea was too broad

My first mental model was simple: “convert Markdown to anything.”

It sounded focused. It was not.

Every output format carries a different promise:

• A Word document should remain editable.
• A PDF should be visually stable and printable.
• HTML should be clean enough to publish or reuse.
• An image should be sharp at the dimensions the user selected.
• Markdown extracted from PDF, Word, or HTML should be readable, not merely technically valid.

A universal Convert button would have hidden those differences. It also would have produced a product that was easy to demo and frustrating to use.

The first important decision was therefore not about code. It was to give each workflow its own interface and success criteria.

Markdown to PDF needs page preview and print-aware styling. Word to Markdown needs a cleanup step. A table generator needs row, column, alignment, paste, and CSV controls. Treating these as one feature would have made every workflow worse.

The lesson: scope is not the number of pages you build. Scope is the number of promises you make.

Privacy changed the architecture, not just the copy

“Privacy-first” is easy to place under a logo. I wanted it to describe observable behavior.

In MDFold, the document content stays in the current browser during editing, preview, conversion, and export. There is no upload step for the converter to work. Saved preferences and reusable templates stay on that device as well.

That choice created useful constraints:

• There is no upload queue.
• A slow connection does not become a slow conversion after the app has loaded.
• The server does not need to store a stranger’s report, contract, draft, or source code.
• Clearing browser data can remove locally saved preferences and templates.
• Moving to another device does not automatically bring those local settings with you.

The last two points matter. Local storage is a privacy advantage, but it is not cloud sync. A trustworthy product should explain both sides of that trade-off.

This also gave me a simple product test: if a conversion required sending the document to an application endpoint, the implementation had broken the product promise.

The editor became the product

I originally thought of the editor as a place to paste input before clicking a button.

That was wrong.

Conversion is rarely a one-click event. People notice a heading that should be smaller, a table that is too wide, an image that needs a better URL, or a code block with a missing language label. They need a correction loop:

1. Write, paste, or open the source.
2. Inspect the result.
3. Fix the source or presentation.
4. Export.
5. Open the exported file and verify it.

MDFold therefore uses a live editor and preview instead of an upload form followed by a download screen.

The source and output remain visible together, so formatting problems can be fixed before export.

This led to several features that did not look essential in the first sketch but became important in real use:

• focus mode for long editing sessions;
• fullscreen mode for detailed review;
• quick actions for headings, code, lists, and tables;
• 24 document themes across business, minimal, academic, technical, and creative styles;
• editable colors, fonts, type size, line height, and page spacing;
• a short first-use tour that can be dismissed and reopened;
• separate write and preview views on a phone-sized screen.

None of these is impressive in isolation. Together, they shorten the correction loop.

That is a better product goal than maximizing the feature count.

“It rendered” was not a sufficient test

The biggest trap in document tools is trusting the preview.

A preview can look perfect while the downloaded file is malformed. A file can download successfully and still be unreadable by the program the user opens next.

I used a representative Markdown document containing:

• H1, H2, and H3 headings;
• bold and italic text;
• ordered and unordered lists;
• links and blockquotes;
• a table;
• a fenced JavaScript block;
• inline and block math;
• an external image.

Then I checked the output according to the format:

Output	What I checked
DOCX	The file is a readable Word archive and the document structure is present
HTML	Headings, rich text, links, code, and table markup are present
PNG	The downloaded image has the requested dimensions and remains sharp
JPG	The file is a valid JPEG rather than renamed PNG data
PDF	The print preview, pagination, background styling, and save control work
Markdown	Reading order and useful structure survive the source conversion

I also tested the rendered site, not only the individual conversion functions. The current check covers the homepage, all eight tools, the tools directory, and the practical guides.

This caught a class of problems that unit-level checks miss: a converter can be correct while its route fails to render, its first-use overlay blocks the download button, or its phone layout creates horizontal overflow.

The lesson: test the artifact in the program that will consume it, and test the complete user path that creates it.

PDF to Markdown forced me to be honest

PDF is a presentation format. Markdown represents document structure. Moving from one to the other requires inference.

A digitally generated PDF with a clear reading order may convert into useful Markdown. A multi-column layout can scramble that order. A scanned PDF may contain no useful text layer at all. Complex tables, positioned captions, footnotes, and decorative layout can require cleanup.

A successful extraction still needs a human check for reading order, headings, tables, and missing content.

I could have hidden those limitations behind “AI-powered” language or claimed support for every PDF. That might improve a landing-page headline, but it would make the product less useful.

MDFold instead gives the extracted Markdown back in an editor. The user can inspect the text order, correct headings, repair a table, and compare the preview before downloading.

Some files need OCR. Some need manual cleanup. Some are better handled by a specialized document-reconstruction tool.

Saying that clearly is part of the feature.

AI accelerated implementation, but it did not own the decisions

I used AI-assisted development throughout the build. It was especially helpful for:

• generating a first implementation from a precise interface specification;
• applying the same behavior across several converter pages;
• proposing test cases;
• finding inconsistent labels and repeated layout problems;
• turning a failure into a reproducible check.

It was less useful when the instruction was vague.

“Make the converter better” produces plausible changes.

“At 390 × 844, the first-use guide must not create horizontal overflow; the editor, preview switch, and download action must remain reachable” produces work that can be judged.

The speed did not come from asking an AI to build an entire product in one prompt. It came from repeatedly doing four things:

1. Define one observable outcome.
2. Implement the smallest coherent change.
3. Run the real workflow.
4. Keep the failure as a permanent check.

AI made each loop faster. It did not remove the need for the loop.

The redesign happened after the product worked

My first version was functional, but the interface still made people work too hard to understand it.

The tools were not visible early enough. Example content looked too much like user content. Long documents needed more space. First-time users needed guidance, but a large welcome dialog would interrupt returning users.

The fixes were small and specific:

• move the actual workspace higher on the page;
• label bundled content as an example;
• add editor focus and fullscreen modes;
• show a brief guide only on the first converter visit;
• remember dismissal locally;
• keep a “Quick tour” control for anyone who wants it again;
• make the phone layout switch cleanly between writing and previewing.

The most valuable design work was not adding visual decoration. It was removing moments of uncertainty.

What I deliberately did not build

Fast shipping only works when “not now” is a real answer.

I left out:

• accounts;
• cloud document storage;
• cloud template synchronization;
• payments and subscription tiers;
• team workspaces;
• an opaque “AI cleanup” button;
• a promise of perfect conversion for every source file.

These features may make sense later. In the first release, they would have expanded the security surface, privacy explanation, support burden, and number of states that needed testing.

The free, accountless product is not a temporary gap in front of the real product. It is the simplest complete version of the promise: open a tool, convert a document, inspect the result, and leave with a usable file.

What I would do differently

If I started again, I would make three changes.

1. Write the acceptance tests before the interface

“Supports Markdown tables” is vague.

“A table with alignment markers, inline emphasis, and a long cell remains readable in preview and export” is a test.

Starting with the second sentence would have prevented several rounds of polishing the wrong thing.

2. Build difficult sample files on day one

A friendly demo document gives false confidence. Every converter needs a representative file and an adversarial one.

For MDFold, that means wide tables, long code lines, nested lists, broken image URLs, non-Latin text, scanned PDFs, multi-column PDFs, and Word files with inconsistent styles.

3. Treat explanations as part of the interface

Users need to know why a scanned PDF produces little text, why PDF background colors can depend on a print setting, and why local templates do not appear on another device.

A clear limitation at the right moment prevents more frustration than another generic feature badge.

Three principles I am keeping

After building and revising MDFold, these are the principles I would carry into any small developer tool:

1. Every format is a separate promise. Define what a successful output means before implementing it.
2. Privacy must be visible in the data flow. “We care about privacy” is not a substitute for knowing where the file goes.
3. The exported artifact is the product. A beautiful preview does not rescue a broken download.

The first version took three days. Making it trustworthy is an ongoing process of finding vague promises and replacing them with specific behavior and repeatable checks.

You can try MDFold without creating an account.

If you test it, I would especially value one kind of feedback: what file or Markdown construct produced a result you did not expect?

That is more useful than “looks great,” and it gives me the next real test case.`