md2rich

Books as code: write and publish a book from Markdown + Git

A book is the longest thing most writers will ever publish, which makes it the perfect candidate for the write-once, publish-everywhere approach. "Books as code" treats your manuscript like source code — plain Markdown files in a Git repository — and compiles that single source into EPUB, PDF, and web-ready HTML. Here is what the workflow looks like in 2026 and why it fits neatly alongside client-side Markdown conversion.

The phrase "books as code" has been circulating in the writing community for years, and a fresh HackerNoon feature repopularized it in August 2026 by walking through exactly how a manuscript becomes a Git repository of Markdown. The idea is simple and profound at the same time: instead of writing your book inside a word processor's proprietary file, you author each chapter as a .md file in a folder, track every draft with Git, and let a compiler turn that plain-text source into whatever finished format your readers need. The write-once, publish-everywhere philosophy we keep returning to on this blog finds its most ambitious expression in a full-length book.

Why does this matter to a Markdown writer? Because a book is the case where the payoff is largest. When a 300-page manuscript lives as 12 clean Markdown files, you get version control, collaboration, automated builds, and the ability to ship to multiple stores from one source — things a word processor simply cannot give you. And the skills are the same ones you already use for a blog post on Medium or a long-form X Article: write in Markdown, then convert at publish time.

What "books as code" actually means

Books as code models a book the way developers model software. The manuscript is a directory of source files; the finished book is the compiled output. Practically, that means:

This is the same mental model we apply to Markdown-to-rich-text conversion at a smaller scale. The file is the truth; any rendered output is just one view of it. A book just makes the stakes — and the payoff — bigger.

The toolchain: from Markdown source to finished book

You do not need an expensive publishing suite to work books-as-code. A handful of free tools cover the full pipeline from a folder of Markdown to a store-ready EPUB or a hosted web book:

For storefront publishing, Leanpub has long accepted Markdown manuscripts and lets you sell in-progress "early access" books, while GitBook is a hosted option that syncs your Git-backed Markdown to a web book automatically. The common denominator: your source stays plain Markdown, and the tooling handles the formats.

A concrete books-as-code workflow

Here is a realistic end-to-end workflow that mirrors the HackerNoon approach. Start with a Git repository and a source folder:

# set up the manuscript repo
$ mkdir my-book && cd my-book
$ git init
$ mkdir manuscript

# a chapter is a Markdown file
# manuscript/chapter-01.md
# # Chapter 1: Why Plain Text Wins

Author each chapter as a normal Markdown file. Keep all images in a folder (say manuscript/images/) and reference them with relative paths. Then compile the whole book. With Pandoc, a complete build to EPUB looks like:

# compile all chapters into one EPUB
$ pandoc manuscript/*.md \
    --metadata title="My Book" \
    --metadata author="Your Name" \
    --toc --toc-depth=2 \
    -o my-book.epub

# and a web-ready HTML version from the same source
$ pandoc manuscript/*.md \
    --standalone --toc \
    -o my-book.html

Because every run reads the same Markdown, you can wrap the build in a small script and regenerate EPUB, PDF, and HTML with one command. That is the "code" in books-as-code: your manuscript is a buildable project, and a fresh copy is one git clone away.

From manuscript to reader — and from manuscript to post

The books-as-code workflow does not stop at EPUB and PDF. The exact same Markdown source that compiles into a book also becomes the shorter content you use to promote it — the LinkedIn announcement, the X Articles thread, the Medium excerpt. This is where the two halves of the pipeline come together, and it is the piece most books-as-code guides skip.

Consider this snippet lifted straight from a manuscript chapter:

# What I Learned Writing a Book in Markdown

**Your words should outlive the tools you use to write them.**

- Plain text is never trapped in a dead format
- Git gives every draft a recoverable history
- One source builds EPUB, PDF, and the web
- The same file becomes your launch posts

That file compiles into a polished page, EPUB, or PDF through a book tool. But when you want to post the highlights to LinkedIn or X Articles, you run that same Markdown through md2rich and get native rich text: a bold headline, an emphasized first line, and a clean bulleted list, formatted the way each platform expects.

Here is another example — a short "publishing pipeline" post built from the same chapter content:

# My Publishing Pipeline in 2026

Write chapters in **Markdown**.
Compile with [Pandoc](https://pandoc.org/).
Self-publish as **EPUB**.
Promote with [md2rich](https://md2rich.com/).

Like our example in the Jorge walkthrough, the pattern is identical whether the output is a book, a website, or a social post: write once in Markdown, let the right tool produce the format each destination needs. A book is just the largest single artifact in that family.

Books as code and privacy: keep the manuscript on your machine

A manuscript is sensitive. Drafts, unpublished chapters, and even finished work you have not released should not live on a third-party server you do not control. The books-as-code approach is well suited to a privacy-first posture precisely because the heavy lifting — compiling and converting — happens on your own machine with local tools like Pandoc and mdBook. The only service you may need is Git hosting, and you can self-host or use a private repository.

This is the same reason we built md2rich the way we did: the converter runs entirely in your browser and uploads nothing. Your Markdown — whether it is a chapter or a two-line announcement — never leaves your device. When you move from a finished book to its promotion, converting the source to rich text client-side keeps the whole production chain local. For the wider picture on that philosophy, our client-side vs cloud converters comparison lays out the trade-offs.

Is books as code right for you?

Books as code is not for every writer. If you need precise page layout, rich typography control, and a tightly designed interior, a dedicated typesetting tool still beats a Markdown pipeline. And if you are uncomfortable at a command line, the learning curve of Git and Pandoc may feel like a detour from writing.

But if you already live in Markdown — which, if you are reading this blog, you probably do — the step is smaller than it sounds. The chapter files are just longer versions of posts you already write. Git is a skill you may already have. And the payoff is real: a manuscript that is versioned, portable, and buildable into every format from a single source, plus launch posts generated from the same files. That is the write-once, publish-everywhere idea applied to the biggest project a writer can take on.

The bottom line

Books as code turns the manuscript into source code: Markdown files in Git, compiled into EPUB, PDF, and web output by free tools like Pandoc, mdBook, and Quarto. It gives you version control, portability, and one source of truth for every format — and the same source feeds your launch posts through a Markdown-to-rich-text converter. Whether your next project is a 300-page book or a one-page newsletter, the principle holds: keep your writing in plain Markdown, publish everywhere, and never let a tool hold your words hostage.

FAQ

What does books as code mean?

Books as code is the practice of authoring a book as plain-text Markdown files versioned in a Git repository, then compiling that single source into multiple formats such as EPUB, PDF, HTML for the web, and MOBI. Chapters are files, headings and lists are just Markdown, and every change is tracked like software.

What tools do I need to write a book in Markdown?

You only need a text editor and Git. To compile the book into finished formats you can use a free tool like Pandoc, mdBook, or Quarto, or a service like Leanpub or GitBook. Each takes your Markdown source and produces EPUB, PDF, or web output, so you can pick whichever matches your workflow.

Can I publish a Markdown book to Amazon or Apple Books?

Yes. Most self-publishing platforms accept the EPUB format, which is the standard output of Markdown-to-book tools. You compile your Markdown source to a validated EPUB and upload it to Amazon KDP, Apple Books, or Kobo. Keeping the Markdown source means you can regenerate every store-specific build from one file.

How is books as code different from writing in a word processor?

A word processor locks your manuscript in a proprietary binary. Books as code keeps your writing as plain Markdown any tool can read, gives you full version history and branching with Git, and lets you produce every output format from one source. You trade some visual layout control for portability and automation.

How does md2rich fit into a books-as-code workflow?

md2rich converts your Markdown source into formatted rich text you can paste directly into LinkedIn, X Articles, Medium, or Notion. The long-form book and the shorter launch posts come from the same Markdown files: compile the book to EPUB or PDF, and use md2rich client-side to publish the promotions without uploading your work anywhere.

One Markdown source. Publish it anywhere.

Write your book — or your next post — in Markdown, convert it to rich text locally with md2rich, and paste into LinkedIn, X Articles, or Medium with formatting intact. No upload, no account, no lock-in.

Try md2rich