Should I vibe code
Presentation, video, and design tools with a zooming visual canvas
The zooming canvas is a weekend. The conference-room projector at 1024x768 is the product.
?
Their verdict, the Plus (Individual) 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
An infinite canvas with a camera that eases between framed regions is one of the most satisfying things you can build in a weekend, and tldraw or a bare SVG viewBox will get you most of the way there before dinner. That is not the product. The product is the ninety seconds in a meeting room where you plug into a projector that reports 1024x768, a font you licensed for the web is not installed on the loaner laptop, the venue wifi is captive-portalled, and two hundred people are watching you drag a window. Prezi's paid tier is mostly a list of answers to that scenario: offline desktop app, presenter view on a second display, PDF export, PowerPoint import, portable presentations. None of those are hard individually and all of them are boring, which is exactly why your version will not have them. Build the zoom for the joy of it. Then present from a PDF like everybody else.
What actually breaks
not "if". the specific failures.
- The projector, when the canvas is laid out for your 16:10 retina display and the room gives you 4:3 with a hard edge crop through the middle of a heading
- Fonts, which resolve beautifully on your machine and fall back to Times on anything else, moving every absolutely positioned element you carefully aligned
- The network, because a canvas that streams images from your own bucket is a blank rectangle behind a captive portal, and there is no offline mode unless you built one
- Presenter view, which needs a second window on a second display talking to the first one, and is a genuinely fiddly bit of work nobody budgets for
- Export, which is the feature people actually ask for — a PDF or MP4 of a zooming canvas is a render pipeline, not a screenshot
- PowerPoint import, where the entire corpus of decks people already own lives, and which is a lifetime of format edge cases
- The file format, since your deck is a bespoke JSON blob only your renderer understands, and a schema change six months in silently mangles a deck you cannot re-create
- Motion sickness, which is a real complaint about zooming presentations and the reason the easing curve and the maximum zoom rate need thought rather than defaults
Is that you?
the verdict is a default, not a law
- You present from your own machine, on a screen you have tested, with the file local
- The deck is disposable — a conference talk, a demo, something you will not need to open in two years
- There is an export to PDF or images before there is anything else, so the content survives the tool
- The zoom is the point, and you are building it because you want to build it
- Somebody else has to present from it on hardware you have never seen
- The decks are the record — board packs, client proposals, anything you will be asked to reopen
- You need PowerPoint import, because that is where every deck your colleagues already have lives
- You would be blocked if the renderer broke an hour before the meeting
If you build it anyway
the checklist, then the prompt that enforces it
- Write the exporter first. If the deck can render to PDF and to a folder of PNGs on day one, every later problem is an inconvenience rather than a disaster.
- Version the document schema from the first save and write the migration for v1 to v2 before you need it. A bespoke canvas format with no migrations is how decks stop opening.
- Design for the worst screen you will ever be given, not your own. Test at 1024x768 and 1280x720, and make the camera fit a frame to the viewport rather than assuming an aspect ratio.
- Embed or subset your fonts. Do not rely on the presenting machine having anything, and check what happens to layout when a fallback is used.
- Make it work offline. Bundle assets, cache aggressively, and prove it by presenting with the network off — conference wifi is not a supported dependency.
- Cap the zoom rate and use a gentle easing curve. Fast continuous zoom makes a measurable share of any audience feel ill, which is the criticism the whole category has earned.
- Autosave to local storage as well as the server, and keep a few snapshots. The failure that actually happens is a crash mid-edit the night before.
I am building a zooming-canvas presentation tool: objects placed on an infinite canvas, named frames, and a camera that eases between them. Treat losing or failing to render a deck as the only real failure, and build defensively against it.
1. Start with the document model and version it. Every saved deck carries a schema version,
and there is a migration function and a round-trip test before any editor UI exists.
2. Build the exporter second, not last: deck to PDF and deck to a folder of PNGs, driven from
the same layout code as the live renderer. I want the content to outlive the tool.
3. Autosave to IndexedDB or local storage in addition to any server, and keep the last few
snapshots. Assume the browser tab dies the night before a talk.
4. The camera fits a frame to whatever viewport it is given. Never hardcode an aspect ratio
or assume the presenting display matches the authoring display. Add a test at 1024x768.
5. Subset and embed every font used in a deck into the deck itself. If you cannot, warn me in
the editor and show what the layout looks like with the fallback.
6. Make presentation mode work with the network disconnected. Bundle or cache all media, and
give me a way to verify offline readiness before I leave for the venue.
7. Cap zoom velocity and use an ease-in-out curve with a configurable maximum scale change per
second. Explain in the README why this matters for motion sickness.
8. Keyboard and clicker first: arrow keys, space, page up/down, escape, and a black-screen key.
Those get built before any animation polish.
9. If I ask for real-time collaborative editing, push back — say it is a separate project with
its own conflict-resolution problem, and offer a single-writer lock instead.
10. Deliberately out of scope unless I ask again: PowerPoint import, video export, analytics on
who viewed a deck, and shared links to unpublished decks.
11. Finish by reminding me that the paid product's value is offline mode, presenter view, PDF
export and PowerPoint import — the boring list — and ask which of those I am willing to own.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
You present for a living, to rooms you do not control. Nineteen dollars a month on the annual plan buys the offline desktop app, presenter view, PDF export and PowerPoint import, and the value is entirely in the fifteen minutes before a talk when something is wrong with the room. If you only present from your own laptop to your own screen, keep the weekend project — and honestly, look at reveal.js first, which is free and already handles the clicker, the presenter view and the PDF.
$19/mo is cheaper than your weekend.
Keep the deck in a documented, versioned JSON file that lives on disk rather than only in a database, and make the exporter a first-class feature: PDF and a folder of images means the content survives even if the renderer does not. If you ever want out, a PDF opens in every meeting room on earth, and rebuilding a static deck from exported frames is an afternoon. The thing that makes exits painful in this category is a proprietary layout format with no export and no schema migrations, so do not create one.
The original open-source zooming presentation framework, and the closest thing to a Prezi clone that already exists.
HTML presentation framework with presenter view, speaker notes and PDF export already solved.
Infinite-canvas SDK that gives you the pan, zoom and object model for free.
Questions
Is the zooming canvas really that easy?
The core is, yes. A viewBox on an SVG, a list of frames with coordinates, and an easing function between them gets you a convincing demo in an afternoon, and tldraw hands you the pan-and-zoom object model already built. What takes the time is everything downstream of it: export, fonts, offline, presenter view, and a document format that still opens next year.
Why is this DEMO ONLY rather than SHIP IT, if nothing dangerous happens?
Because the gap between the demo and the product is unusually wide here, and it is all unglamorous work you will not do. Nothing breaks that hurts anyone else — the worst case is your own talk going badly — but you will not end up with something you trust in a room you do not control. That is the definition of the band: build the v0, enjoy it, do not plan your conference season around it.
Should I just use reveal.js?
Probably, if the goal is presenting rather than building. It is free, mature, and already has speaker notes, PDF export, clicker support and a presenter view — the exact list of things a homemade tool takes months to acquire. Build the zooming canvas if the canvas is the interesting part to you, and keep it separate from the deck you actually have to give.
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.
An interactive deck is not a file, it is a runtime. Every embed you ship is compatibility you owe forever.
reveal.js is MIT and free. What Slides.com sells is a URL that still resolves on the morning of the talk.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice