Should I vibe code
Build interactive presentations with hotspots, layers, and simple animations
An interactive deck is not a file, it is a runtime. Every embed you ship is compatibility you owe forever.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-05.
?
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
Gamma's entry is about generated content and Pitch's is about performing a deck in a room with a projector you have never met. Genially is neither, because the thing it produces does not get presented — it gets embedded. A finished genially lives in an iframe on somebody's course page, intranet or blog, which quietly converts what you are building from an editor into a runtime you owe backward compatibility to for as long as that page exists. Every hotspot, layer, tooltip and animation you ship becomes a contract with content authored two years ago against a renderer you have since rewritten twice. The editor is also harder than it looks from outside: a layered canvas, per-object animation timing, an interaction model an author can hold in their head, and an export that survives leaving your domain. Your weekend goes into the editor. The part you will not have built by Sunday is the promise that other people's pages keep working.
What actually breaks
not "if". the specific failures.
- Backward compatibility, which is the whole game: content authored against v1 of your renderer has to keep animating correctly after you rewrite the animation engine, and there is no migration because the content lives on other people's pages
- The embed, which is your uptime becoming a lecturer's uptime — their course page shows a grey rectangle at 9am on a Monday and they have no idea who to email
- Layered canvas editing, where hit-testing, z-order, grouping and undo across nested objects is a solid month of work that nobody sees
- Fonts, because an interactive piece embedded on a third-party domain either ships its own webfont with the right licence or renders in something else entirely
- Export, since a genially that exists only at your URL cannot be handed over, marked, archived or attached to anything
- Anything the author pastes in: an embed field that accepts arbitrary HTML puts your script inside somebody else's page, which is a cross-site problem with your name on it
- Accessibility, which for click-to-reveal content is a genuine design problem rather than an ARIA attribute — keyboard traversal, focus order, and a text alternative for the whole interaction
- Mobile, where the hotspot that was obvious at 1400px is a four-pixel target and the layered canvas does not reflow at all
Is that you?
the verdict is a default, not a law
- The output is a self-contained folder of HTML, CSS and assets that runs from a file path with no server
- It is for your own content and you are the only author, so a renderer change is your problem for an afternoon
- You build on reveal.js or H5P and spend your time on the authoring experience rather than the runtime
- Nothing is embedded anywhere you do not control, so unpublishing actually unpublishes
- Other people will embed the output in pages you cannot edit, because you have just promised them permanent compatibility
- It renders author-supplied HTML or scripts inside an iframe on a third-party domain
- It is going into a school or an LMS, where SCORM packaging, grade passback and student data are a different product with different law attached
- You have no export, which means every piece of content anyone creates is hostage to your hosting bill
If you build it anyway
the checklist, then the prompt that enforces it
- Define a versioned content format on day one, store the version with every document, and keep old renderers reachable. This is the only decision on this page you cannot make later.
- Export before publish. If a piece cannot be written out as a self-contained folder that runs offline, do not add a share link.
- Build on an existing runtime — reveal.js for linear, H5P for interactive — and put your effort into authoring rather than reimplementing playback.
- Never render author-supplied HTML or script. Offer a fixed list of embeddable providers and sanitise everything else.
- Serve embeds from a separate origin with a strict content security policy, and treat their availability as production even though it feels like a side project.
- Design for keyboard and screen reader from the first interaction type, because retrofitting focus order onto a layered canvas is a rewrite.
- Test at 360px early. A hotspot interface that only works on a laptop excludes most of the audience for this kind of content.
- Give every published piece a stable URL and a documented unpublish behaviour, so a removed genially degrades to a message rather than to a broken frame.
I am building an editor for interactive presentations with hotspots, layers
and animation. The output gets embedded in pages I do not control, so treat
the published format as a long-term contract rather than an implementation
detail.
1. Design the content format first: versioned, declarative, with the version
stored on every document. Tell me why old renderers must stay reachable.
2. Build the exporter before the share link. A published piece must come out
as a self-contained folder that runs from disk with no server.
3. Build on an existing runtime — reveal.js or H5P — and put the effort into
authoring rather than reimplementing playback.
4. Never render author-supplied HTML or script. Offer a fixed allowlist of
embeddable providers and sanitise everything else.
5. Serve embeds from a separate origin with a strict content security
policy, and treat that origin as production even though it feels like a
side project.
6. Keyboard and screen-reader support come with the first interaction type,
not later. Retrofitting focus order onto a layered canvas is a rewrite.
7. Test at 360px before adding a second interaction type. A hotspot that
only works on a laptop excludes most of the audience.
8. Ship fonts with the piece under a licence that permits it, or fall back
deliberately. Do not assume the embedding page has anything installed.
9. Give every published piece a stable URL and a defined unpublish behaviour
that degrades to a message, never to a broken frame.
10. Out of scope unless I ask, and say so rather than half-building it:
SCORM and LTI packaging, quiz scoring, analytics on viewers, and
anything that stores data about students.
11. Finish by telling me that the compatibility promise, not the editor, is
the thing I would be buying.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
The moment anyone other than you authors content, and again the moment anything is embedded somewhere you cannot edit. Those are the two commitments that outlast enthusiasm: a colleague who needs the editor to make sense without you, and a page on the internet that expects your renderer to behave the same way next year. Build your own if the audience is your own slides and the output is a folder you can zip. The alternative is not that your version is worse — it is that you have taken on a compatibility obligation with no end date in exchange for a subscription you were annoyed about.
The exit is entirely determined by one early decision: whether a published piece can be exported as a self-contained folder that opens from disk. If it can, leaving costs nothing — you hand people their content and turn the server off. If it cannot, every piece anyone made is trapped behind your renderer, and the people who embedded it lose their page rather than just their file. So build the exporter before the share link, keep documents in a versioned JSON format with assets beside them, and if you ever shut down, replace embeds with a static snapshot rather than a 404. Somebody's course page has been pointing at that iframe since 2027.
Open-source interactive content framework with a large library of content types and LMS integration, which is the closest thing to this product.
Long-running HTML presentation framework, worth building the authoring layer on top of rather than replacing.
Questions
Pitch is DEMO ONLY at 34 and this is DEMO ONLY at 36. What actually separates them?
Where the artefact ends up. A Pitch deck is performed once, live, and its failures are a font substitution and a projector aspect ratio — bad, but over by lunchtime. A genially is published and embedded, so its failures are permanent and belong to whoever put the iframe on their page. Same verdict, different reason: Pitch's gap is the last ninety minutes before a meeting, and this one's is the two years after you stop maintaining the renderer.
Why is maintenance the highest number on this entry?
Because there is no migration path for content you do not host the page for. A normal app can rewrite its data model and run a migration over its own database. Here, the presentation is a live document rendered by your code inside somebody else's page, and every visual behaviour you shipped — timing, easing, stacking, how a hotspot responds on touch — is something an author relied on. You cannot patch their expectations, so you carry the old behaviour, and that accumulates for as long as the product exists.
What is the version worth building?
An authoring layer over a runtime somebody else maintains. Take reveal.js or H5P, spend all your effort on the editor — the part Genially is genuinely good at and the part that has nothing to do with playback — and export self-contained folders. You get the thing you wanted, the compatibility burden belongs to a project with more users than you, and unpublishing means deleting a directory.
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.
AI slide generation is a prompt and a template. The output was always going to be disposable.
The canvas is a weekend. The font licence you embedded in that merch export is a letter from someone's lawyer.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice