Verso: one JSON source, decks branched per audience
Verso defines presentations as JSON instead of slide documents, so one source can branch per audience and export to PDF, HTML, or PNG cleanly.
Verso is a presentation system that treats your deck as data, not as a document. You define content in JSON, render it to HTML, and branch a single source into audience-specific decks without copy-pasting slides. One canonical source, many tailored outputs, all reproducible from a build step.
I built Verso under Starside Labs because the slide-as-document model breaks the moment you present the same material to three audiences. A board wants outcomes, engineers want architecture, and a sales room wants the story. With a document, that means three files drifting out of sync. With Verso, it means one source and three paths.
Why is content-as-data better than slide-as-document?
A slide document mixes content, layout, and audience intent into one opaque blob. When the message changes, you hand-edit every variant and hope nothing rots. Content-as-data separates those concerns: the JSON holds what you are saying, the renderer decides how it looks, and a branch decides who sees what.
That separation buys you the same things version control and typed schemas buy any codebase. You can diff a deck, review it in a pull request, and validate it before it ever renders. Verso uses Zod schema validation so a malformed slide fails at build time, not on stage.
How does path-based branching work?
Each slide can be tagged for a path, and a path represents an audience. When you build the board deck, Verso resolves the board path and drops everything that does not belong. The engineer deck pulls the same shared slides plus the architecture detail the board never sees.
Crucially, the shared material lives once. Fix a number on the shared slide and every branch inherits the correction. This is the core promise of the Verso project: you stop maintaining parallel decks and start maintaining one.
What about variables across slides?
Verso supports variable interpolation across the whole deck. Define a client name, a quarter, or a metric once and reference it everywhere. Re-pitching the same deck to a new client becomes a single value change, not a find-and-replace tour through forty slides.
That sounds small until you have run the same workshop for SIA, Maybank, and Prudential in one month. Variables turn a bespoke rebuild into a parameter swap.
What can you export, and what is the stack?
A Verso deck exports to PDF for handouts, HTML for the browser, or PNG when you need slides as images for another pipeline. The same JSON drives all three, so the PDF a client receives matches the HTML you presented.
The stack is deliberately lean: TypeScript for the model, Preact for rendering, Vite for the build, and Zod for validation, running on Node 20 or later. It is small enough to read in an afternoon and typed enough to refactor with confidence. The code is open source on GitHub, and the project overview lives on the Starside Labs site. If you build decks for more than one audience, treating them as data will save you the duplication tax every single time.