Your Slidev or reveal.js deck is already a self-contained web app. Skip the public deploy, the screenshot, and the PDF flattening: run the build, zip the dist folder, and turn it into one private link that keeps every fragment, transition, and code highlight stepping exactly as it did locally.
You wrote the deck in Markdown. You stepped fragments one click at a time, highlighted the exact line of the code sample so the room watched it light up, picked a transition that lands the punchline on the right beat. Slidev or reveal.js compiled all of that into a real web app that runs in a browser. Then it's time to share, and the tooling quietly steers you toward throwing the stepping away.
That's the specific loss for a developer deck. A marketing deck survives being flattened — it's mostly static slides anyway. A code-walkthrough deck does not. The whole argument of the talk lives in the sequence: reveal this bullet, then this one, now highlight lines 12 to 14, now diff against the fixed version. Export to PDF and that sequence collapses into one frozen frame per slide. The build steps are gone, and with them the pacing you spent the most time on.
Export to PDF and every click-step flattens — the fragment reveals gone, the code-highlight walk-through gone, the transitions gone. Or deploy it to a public site: now you're configuring Pages, wiring DNS, making a repo public, and broadcasting a half-tuned internal deck to the open web and its crawlers. Neither is what you wanted. You wanted to hand one person a link that runs the deck you actually built.
Here's the thing Slidev and reveal.js users sometimes forget: the build output is a finished, portable web app. You don't need a server to run it. slidev build writes a dist/ folder of plain HTML, JavaScript, and assets. reveal.js exports the same shape — an index.html plus its bundle. That folder is the whole deck. Open index.html locally and it runs, transitions and all.
So the question isn't "how do I render this for sharing." It's "where do I put a folder of static files so one person can open it as a link." That's a much smaller, much more honest problem — and it's exactly the slice a private static host is built for. There's a page for hosting a Slidev deck and one for hosting a reveal.js deck that walk the same path tool-by-tool.
The flow is short enough to do between standups.
1. Build to static. For Slidev: slidev build produces dist/. For reveal.js: your static export, or the dist/ from your bundler. Open the folder's index.html in a browser once to confirm it runs offline — if it runs locally with no dev server, it runs anywhere, because there's no server in the loop.
2. Zip the folder. Compress the whole build directory into a single .zip. Slidev and reveal builds are always multi-file — JS chunks, fonts, image assets — so they travel as a zip to keep the relative paths between files intact.
3. Drop the zip on miinideck. Drag it in. You get back an unguessable private link. The viewer opens it with no account and no signup wall, and steps through the deck with the arrow keys exactly as you did locally. The fragments reveal. The code highlights walk line by line. The transitions fire. Because it's the real built deck running, not a recording of it.
A deck is rarely meant for the open web. It's for the people in the room, the team channel, the one investor, the workshop cohort. A public deploy is the wrong shape for that: it's indexable, it's discoverable, and it commits you to maintaining a clean public URL for something inherently provisional — a talk you'll revise next month, an internal architecture deck that shouldn't leak.
miinideck inverts the default. The link is unguessable and no-indexed, so it won't surface in search and the only people who reach it are the ones you send it to. "Anyone can open it" means anyone you handed the link to — not the public.
Two controls fit the lifecycle of a deck:
Static hosting runs anything that lives in the browser. If your reveal.js deck fetches from a public API at view time, that call still fires — the viewer's browser makes it, same as on your machine. Client-side JavaScript, embedded interactive demos, web-component slides: all fine, because the browser does the work.
What miinideck does not run is your server. No server-side rendering on our side, no database, no build step we execute. If your deck depends on a backend you control — a private API behind auth, server-rendered slides, a data pipeline feeding live numbers — that backend has to live somewhere built for servers. Vercel and Netlify run server functions and connect to a database; that's the right tool for the dynamic half. The clean split: host the deck on a private miinideck link for the delivery and the privacy, and let it talk to your backend wherever that backend already runs. Static slice here; server-side there.
For most Slidev and reveal.js decks, though, the whole thing is static. The slides, the code, the animations — all of it ships in the build. No backend to worry about, and the export is just the three steps above.
If you're a developer, the deck is one of several self-contained HTML things you produce in a week — alongside a Vue app, an Astro site, or some other vibe-coded artifact. Same delivery problem, same answer: build to static, zip, drop, get a private link. The deck just happens to be the case where flattening to PDF is most obviously a loss, because the whole point of a code-walkthrough deck is the stepping.
So treat the build output as the deliverable it already is. You did the hard part when you wrote the slides in HTML. Don't undo it at the last step by handing someone a screenshot. Build it. Zip it. Drop it. One private link, the real deck running inside it.
Client-side encryption tools turn your page into an encrypted file, so the protection and the artifact are the same object — every edit means re-running the tool and re-uploading. What that actually costs, the salt setting that decides whether your old share links survive, and when a hosted password is the better trade.
Running the studio out of one folder per client is a good structure for making the work. It stops at the point where the client has to open it — a private repo needs a GitHub account, and Pages built from one is public by default. What the handover step actually needs, and how to add it without breaking the folder.
A .json Lottie is not a page — hand it to a client and they get a wall of numbers. What it takes to turn one into something that opens in any browser, and why the answer is smaller than the tooling suggests.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.