ai literacy / devrel enablement

Run a Live AI Product Demo
like a Founding DevRel Lead

Press S for presenter view · T to switch themes · ← → to navigate

Open Design DevRelgithub.com/nexu-io/open-design · 30 min session

Hi everyone. This session is the playbook a founding DevRel lead uses to run a live AI product demo — not a recorded walkthrough, a real session where the prompt in front of the audience is theirs, and the output is a runnable file by the time we're done.

The deck itself is the proof point: it's built with presenter mode, so you're seeing the audience view while my screen carries the current slide, the next slide, the full script, and a timer — one Open Design plugin produced everything you're looking at.

Four facts to hold onto for the rest of this session: Apache-2.0 open source, runs locally, BYOK, no sign-up. That's what makes a live, unscripted demo safe to run in front of a room — no cloud dependency to go down mid-pitch.

30 minutes, five parts, questions welcome anytime. Let's go.

agenda

Five things on the agenda

01Why now · Live demos are outperforming decks in AI evaluations~5min

02Workflow map · From a one-line prompt to a runnable file, live~6min

03Pilot & risk control · The 30-minute session format, and the fallback plan~8min

04Live demo · Running this very deck in presenter mode~8min

05ROI + rollout plan + Q&A~3min

// part 01 · why now

Buyers stopped trusting canned demos —
they want their own prompt, live.

✅ What buyers expect

A prompt from the room, not a rehearsed script — proof the tool works on their real problem, not a curated one.

❌ What kills a demo

Pre-recorded video, no visible source, and no good answer when someone asks "what if I ask it X instead?"

💡 Open Design's answer

Local, agent-native runtime — any prompt becomes a real, runnable file in the room, in minutes.

Let's start with why this matters right now.

Look at the card on the left. Prospects have watched a dozen AI product videos this quarter alone. What actually changes a mind is watching the tool take their prompt, not a cherry-picked one — that's the bar now.

The middle card is the trap most demos fall into: a pre-recorded video, no source visible, and the moment someone asks "what if I typed something different" the whole thing falls apart because there's nothing live to show.

Which brings us to the right card — Open Design runs locally and reads full context live, so the agent can take any prompt from the audience and turn it into a real, editable file before the session ends. That's the demo we're about to run.

So what does that workflow actually look like, step by step? Next part.

// part 02 · workflow map

From a one-line prompt to a shipped file in four beats

①

Take the room's prompt

Ask the audience for a real ask — a landing page, a dashboard, a pitch deck — and type exactly what they say.

②

Lock the direction

One click sets palette, typography, and spacing so every following screen stays visually consistent.

③

Generate on screen

The agent writes real, runnable files in the sandbox — the audience watches code compile, not a loading spinner.

④

Hand it over, on the spot

Drop the file into a repo or a Slack channel before the session ends — no "we'll follow up" needed.

This is the workflow map — four beats, and I run through all four live in every session.

Beat one, take the room's prompt. Not a warm-up example — the actual thing the audience says they need, typed verbatim.

Beat two, lock the direction. One click sets the palette, fonts, and spacing, so everything the agent generates after this stays visually consistent — no per-screen tuning live on stage.

Beat three, generate on screen — the moment that sells the room. The agent reads full context and writes real, runnable files in the sandbox, and the audience watches it happen in real time, not a spinner cutting to a finished screenshot.

Beat four, hand it over on the spot. The file goes to a repo or a Slack channel before we move to Q&A — the prospect leaves with something real, not a follow-up email.

So how do we scope this as a repeatable pilot, and what's the fallback if the live prompt misbehaves? Next part.

// part 03 · pilot & risk control

Pilot format & risk controls

01

🎯 Pilot scope: one session, one live prompt

30 minutes, one audience-chosen problem, one agent, one deliverable — repeatable across prospects, not a one-off show.

02

🛡️ Risk control: it runs without the internet

Local-first, so a flaky venue Wi-Fi never stalls the demo; a rehearsed backup prompt is ready if the live one runs long.

03

📊 Success bar: they can name the file

Pass/fail signal: can the audience say what got built and where it lives — a repo link, a preview URL — by the time we close?

Now for the part that gets this funded internally — how we scope the pilot and control the risk of running it live.

First, pilot scope. One session, 30 minutes, one problem the audience picks in the room — not five feature tours crammed into one slot. That's what makes it repeatable across ten prospects a month instead of a single showcase event.

Second, risk control. Because Open Design runs locally, a bad venue Wi-Fi connection never stalls the live moment — the agent and sandbox are on the laptop. If the live prompt runs long, I have one rehearsed backup prompt ready that still lands inside the 30 minutes.

Third, the success bar — and this is the metric that matters to a DevRel manager: can the audience, unprompted, say what file got built and where it lives? If yes, the session earned a follow-up meeting. If no, we adjust the pilot script, not the product.

Put those three together and you have a pilot you can run weekly, not once. Now, the numbers that make the case to fund it.

// part 04-05 · roi + rollout

The numbers that get this funded

# Get Open Design (macOS / Windows · Apache-2.0)
open https://github.com/nexu-io/open-design

# 60K+ Stars · 300+ Contributors · 217+ Plugins · 129 Design Systems
# Cost per live session: $0 in API fees when run BYOK on the presenter's own key

# Keyboard shortcuts for this deck (presenter-mode demo)
S  → open presenter view
T  → switch theme (5 presets)
← → → navigate slides
R  → reset timer
    

Rollout: 1 pilot session this week → 4 DevRel reps trained next sprint → weekly cadence. discord.gg/mHAjSMV6gz

Finally, the numbers and the rollout plan — what I need approved to keep running this every week.

Open Design is Apache-2.0, no sign-up, and BYOK — which matters for ROI, because a live demo session costs nothing beyond the presenter's own API key. Community context: 60K+ stars, 300+ contributors, 217+ Plugins, 129 Design Systems — this isn't a fringe tool the prospect has never heard of.

The keyboard shortcuts here are the exact ones I use live: S for presenter view, T to switch themes, arrow keys to navigate, R to reset the timer. Five themes ship by default, so the same deck reads right in a dark technical room or a bright executive briefing.

Rollout plan: one pilot session this week, four DevRel reps trained on the format next sprint, then a weekly cadence against the pipeline. That's the ask.

Remember — this deck is itself the proof: presenter mode, live script, theme switching, all generated HTML, produced the same way the demo will be run. Thank you — questions, go.

Run a Live AI Product Demolike a Founding DevRel Lead