Show HN: MkSlides makes Markdown slides feel like docs

MkSlides gets the writing workflow right

A tool like MkSlides makes immediate sense if you have ever written docs in Markdown and then had to build a slide deck afterward. The appeal is not mysterious. You already have headings, lists, code blocks, links, and a publishing flow. Turning that into slides with a MkDocs-like workflow feels calm compared with opening PowerPoint and dragging boxes around for an hour.

The Show HN framing matters because it is aimed at builders. This is not a pitch for people who love decorative templates. It is for people who want a deck to behave more like documentation: text files in a repo, readable diffs, repeatable builds, and a mental model that does not fight the way technical teams already work.

That is a real strength. Markdown is still one of the best formats for getting thoughts out quickly. It keeps you focused on order and meaning before layout. For technical talks, internal demos, project updates, and tutorials, that structure-first approach is often exactly what you want.

Markdown slides work best before the deck becomes visual

Markdown is strongest when the slide is mostly an argument. A title, a few bullets, a code block, maybe an image. You can scan the source, understand the flow, and change the order without touching a visual canvas. That is why developer-facing slide tools keep coming back. The source file is simple enough to trust.

The tradeoff appears when the deck needs to become more visual. Most presentations eventually need some degree of spacing, emphasis, hierarchy, and pacing. A product strategy deck may need a comparison table. A sales narrative may need a sharp hero slide. A board update may need charts and callouts. Once you start thinking in visual weight rather than plain sequence, Markdown alone can feel too narrow.

This is not a failure of MkSlides or any Markdown slide tool. It is just the boundary of the format. Markdown is a great authoring layer, but it is not a full editing surface. At some point, people want to click the thing that looks wrong and fix it directly.

The file handoff is still the part that hurts

The old presentation workflow breaks down at the handoff. Someone exports a file, uploads it somewhere, sends it in chat, gets comments in another place, edits a local copy, exports again, and hopes everyone is looking at the latest version. If the deck is for a meeting, the presenter also has to worry about fonts, formatting, screen sharing, and whether the exported file still looks the way it did on their machine.

Docs-style slide tools improve part of that. A build command can create a site or deck from source. That is already cleaner than passing around random versions of a presentation file. MkDocs-like thinking also encourages a published artifact instead of a private local file. That is a better direction.

But many teams still end up treating the result like a file. They download it, attach it, export it, or copy it into another tool. The source may be clean, but the sharing model can still feel old. The moment the deck becomes something you send as an attachment, the version problem creeps back in.

Plain keeps the source-first idea but changes the output

Plain starts from a similar instinct: writing should come before decoration. You can draft with AI, shape the structure, and work from Markdown when that is the fastest path. The difference is what happens after the draft exists. Plain turns the deck, doc, or sheet into a web page you share as a link. The link is the artifact.

That changes the daily workflow more than it sounds. Instead of exporting a PowerPoint file, sending it, and wondering which version people opened, you share a page. If something needs to change, you edit the page. The recipient does not need the right app, the right font setup, or the latest attachment. They open the link.

Plain also does not force you to stay in source mode forever. Markdown is there when you want speed and structure, but you can click elements and edit them directly when the page needs polish. That matters because most real decks move back and forth between writing and layout. A title feels too long. A chart needs more room. A section break needs a stronger visual cue. Clicking the thing is often faster than encoding intent in syntax.

Browser presentation is a better default than export

Presenting from the browser sounds ordinary until you compare it with the usual file dance. A browser page is already where people read, comment, share, and revisit work. If the deck lives there, the presentation mode is not a separate universe. It is the same artifact, shown in a meeting instead of downloaded for one.

PowerPoint export still has a place. Some organizations require .pptx. Some meetings happen in rooms where the old file format is the safest fallback. Plain treats export that way: useful when needed, not the center of the workflow. That is a healthier default for teams that mostly share work online.

MkSlides and similar tools deserve credit for pushing presentations closer to the web. They show that a slide deck does not need to begin life as a binary file. Plain pushes the idea further for everyday office work. The final thing is not a file you publish from source. The final thing is a living web page.

The best workflow depends on who edits after the first draft

If the same technical author writes, reviews, and presents the deck, a Markdown-first tool can be a clean fit. The source file is manageable, the publishing path is predictable, and version control handles the history. For developer talks and docs-adjacent presentations, that is a strong setup.

If more people need to touch the deck, the workflow changes. A founder may want to rewrite the opening slide. A designer may want to adjust spacing. A sales lead may want to change a table during a call. A teammate may not want to open a repo just to fix a sentence. At that point, click-to-edit becomes less of a nice extra and more of a requirement.

That is where Plain has a practical edge. It respects Markdown as a fast way to draft, but it does not make Markdown the only way to work. It treats the deck as a web page, so sharing, editing, presenting, and revising all happen around the same link. For many teams, that is the missing step between developer-friendly authoring and office-friendly collaboration.