Every AI slide tool I’d tried made the same choice: generate text, pour it into an HTML template, and call the result a design. The output always looks like what it is: a form letter wearing a theme. This project is built on the opposite bet: every slide is a single rendered image. No layout engine, no template library, no text boxes floated over a background. A reasoning model decides what each slide should say and how the deck should look, and then an image model renders the whole composition, including typography, graphics, color, and layout, as one 2K image (2752×1536, native 16:9). The deck looks designed because, in the only sense that matters, it was.
Two models, two jobs
The pipeline is two stages because the two halves of making a presentation are different kinds of intelligence. Stage one is narrative architecture: Kimi-K2-Thinking (via DeepInfra) reads the source material. The input field accepts up to 800,000 characters, so “source material” can mean an entire research paper. It works out the audience and intent, picks a narrative arc, and produces a full blueprint: deck title, a design theme with exact hex palette and typography choices, and per-slide titles, content, and a detailed image-generation prompt. Stage two is rendering: Nano Banana Pro (via Runware) takes each slide’s prompt, fused with the deck-wide theme, and paints the finished slide. All slides render in parallel, each with up to three retry attempts and exponential backoff, because a deck that dies at slide 7 of 12 over a transient API error is not a product.
The planning prompt is where most of the iteration went, and a lot of it is rules about what not to do. No “Title: Subtitle” headings, only narrative topic sentences. No generic “Thank you / Q&A” closer. Every data point must be traceable to the source material, no invented statistics to fill a chart. If the source has its own organizational logic, respect it instead of forcing a framework onto it. These read like style pedantry, but they’re the difference between a deck you’d present and the recognizable smell of AI slop, and a reasoning model follows them far more reliably than a chat model does.
There’s also a fork at creation time that changes the planner’s entire approach: presenter slides (minimal text, built to support a live speaker) versus a detailed deck (self-explanatory, built to be read async without you in the room). Those aren’t two densities of the same output. The format instruction changes how the narrative gets constructed, because a slide that works behind a speaker is a bad document and vice versa.
Editing an image like it’s text
The obvious objection to slides-as-images is editing: you can’t click into a text box. The answer is image-to-image: select a slide, type an instruction (“make the title larger,” “shift this to blue tones”), and the model regenerates the composition using the current slide as the reference and the deck theme as context. Every edit pushes the previous version into a persistent history table. The old image is pulled from R2 and stored as a historical version, with the edit instruction recorded alongside, so undo is a real restore, not a client-side trick. Failed slides get a one-click retry that re-enters the same background job pipeline the original generation used.
Generation progress streams to the editor over SSE with a polling fallback, per-slide, so you watch the deck materialize in the thumbnail rail as slides finish in whatever order the parallel jobs complete. And because every slide is already a finished image, the two features that are painful in every DOM-based slide tool are nearly free here: fullscreen presentation mode is just showing images with keyboard navigation, and PDF export is just binding them into landscape pages. No print-CSS archaeology.
Where it sits
The stack is the same foundation as my other product work: Next.js 16, React 19, Vercel AI SDK for orchestration, Drizzle over Neon Postgres, better-auth, and R2 for every generated asset. It’s built as an authenticated multi-user app with per-user presentation ownership, not a demo page with a text box. It belongs to the same family as Product Pics and AgentStudio: tools where the real work is deciding what an image model should be told, and the app around it exists to make that decision well, repeatedly, at volume.