Should I vibe code
Hosted HTML presentations with collaboration, embeds, and developer controls
reveal.js is MIT and free. What Slides.com sells is a URL that still resolves on the morning of the talk.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
This is the rare entry where the homemade version is not a worse copy — it is the same engine. Slides.com is a hosted editor over reveal.js, written by the person who wrote reveal.js, and reveal.js is MIT-licensed, on npm, and renders an identical deck from a file you own. So the build is not "implement a presentation framework", it is "add a dependency and write some HTML", which is why this comes out green where Pitch and Genially do not. Two parts are worth keeping your hands off. The first is the collaborative editor, because three people editing one canvas ninety minutes before a talk is the nastiest problem in this category and you do not have to solve it in order to give a talk. The second is the sharing layer: "private link" in a weekend build means an unguessable URL with no expiry, no access log and no revoke button, and the deck people most want to share privately is the one with the fundraising numbers on slide nine. Build the renderer, keep decks as files in a repo, and export a PDF before you leave the house.
What actually breaks
not "if". the specific failures.
- Fonts. The deck that looked right on your laptop opens on the venue machine with the typeface substituted and every line wrapping one word early, because the face was installed locally and never embedded or subsetted into the build
- The "private" share link, which with no expiry, no access log and no revocation is simply a URL somebody forwarded
- Live presenting, which is a socket that has to survive forty minutes of conference wifi and a laptop that decides to sleep during the Q&A
- Embedded third-party content — a tweet, a map, a Figma frame — each of which is a live network dependency in the middle of your talk
- PDF export drifting from the live render, so the handout and the talk disagree about what slide four said
- Speaker notes, which leak into whatever you hand somebody else the first time the export path forgets they were meant to be private
Is that you?
the verdict is a default, not a law
- The deck is a file you own and you can produce a self-contained PDF of it at any moment
- You are the only author, or your co-authors are comfortable in git
- Sharing means putting a static build behind the authentication you already run
- You actively want the developer-mode half — custom CSS, a theme that matches your product, decks generated from data
- Three people need to edit the same deck at once, ninety minutes before it is shown
- "Private" has to genuinely mean private: a board deck, an unannounced product, a customer's numbers
- The talk depends on a live connection to a server you personally operate
- The deck is due tomorrow and this is procrastination wearing a side project's clothes
If you build it anyway
the checklist, then the prompt that enforces it
- Use reveal.js or Slidev rather than writing a renderer. The framework is MIT, has been tested in front of real audiences for a decade, and the only interesting work left is the theme.
- Make "export a self-contained PDF" the first feature rather than the last. It is the one version of the deck guaranteed to work in the room.
- Embed and subset fonts into the build. Never rely on the presenting machine having anything installed, because it will not.
- Vendor everything the deck loads — images, video, fonts, embeds. A talk should render with the wifi switched off.
- If you build sharing at all, links expire, are revocable and are logged, and the default is off. An unguessable URL is not access control; it is obscurity with a good PR agent.
- Keep speaker notes out of every artefact you hand to somebody else, and write a test that asserts it rather than trusting yourself at 1am.
I am building a web-based presentation tool for my own decks. The renderer is a
solved problem and the risk lives in everything I would bolt around it. Push
back if I ask you to skip any of this.
1. Use reveal.js (or Slidev) as a dependency. Do not write a slide engine, a
transition system or a fragment model from scratch.
2. Decks are plain files — markdown or HTML in a repo. No database, no
proprietary document format, nothing that needs this app to read it later.
3. Build export first: a self-contained PDF and a self-contained HTML bundle
with fonts, images and video inlined. Both working before any editing UI
exists.
4. Prove the offline path. Add a script that serves the built deck with the
network disabled and fails loudly if anything tries to fetch a remote URL.
5. Subset and embed every font. Never emit CSS that falls back to a locally
installed face, because the venue machine does not have it.
6. Speaker notes are private by default. Write a test that renders the shared
export and asserts no note text appears anywhere in the output.
7. Do not implement real-time collaborative editing. If I ask for it, tell me
what conflict resolution on a canvas actually costs and offer me git.
8. If I ask for share links, they get an expiry, a revoke and an access log,
and the default is off. State plainly in the README that an unguessable URL
is not authentication.
9. Do not add analytics that phone home from a deck somebody else is viewing.
10. Out of scope, and say so rather than half-building: live broadcast
presenting, viewer presence, comments, and a template marketplace. If I
turn out to need the live half, $14 a month buys somebody else's socket.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
When you want the live half. Broadcasting a deck to a remote audience with a shared cursor, seeing who opened the private link, or handing a non-technical colleague an editor instead of a repo are all real things, and none of them come free with reveal.js. Pro is $14 a month month-to-month, $10 if you pay for the year, and what it buys is hosting and collaboration — the rendering is free either way.
Barely an exit problem, which is most of the argument. Decks are HTML and markdown in a repo, reveal.js is a pinned dependency you can vendor, and a folder of PDFs works with no software at all. The only state worth worrying about is what accumulated around the deck: view counts, comments, share links colleagues bookmarked. Keep those explicitly disposable, and take a PDF of every deck you actually gave — that is the copy you will want in three years, when the theme no longer builds.
The MIT-licensed HTML presentation framework Slides.com itself is built on, by the same author.
Markdown-driven presentations for developers, with speaker view, PDF export and a component escape hatch.
Questions
Is Slides.com just reveal.js with a UI on top?
The rendering engine is reveal.js, which is open source under MIT, and Hakim El Hattab wrote both. What Slides.com adds is the editor, storage, team folders, live broadcast presenting, viewer analytics and link controls. That is a real product — it is just not the part you were worried about being able to build.
What is the single thing to get right?
Offline. Nearly every way a deck ruins a morning is a network failure: a font that never loaded, an embedded video buffering, a socket that dropped. Build the self-contained export first, rehearse from it, and you have removed the entire risk surface of this project in an afternoon.
Is a deck on my own domain private?
Not unless you put authentication in front of it. A long random path keeps it out of search results and does nothing else — it survives forwarding, browser history, corporate proxies and the screenshot somebody takes of the URL bar. If the deck matters, serve it from behind a login or hand out a PDF.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
A deck is a performance, not a document. Yours has to run once, offline, on a screen you have never seen.
The zooming canvas is a weekend. The conference-room projector at 1024x768 is the product.
The canvas is a weekend. A .pptx that opens correctly on someone else's Windows machine is a career.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice