💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Introduction — Why Demos, Why Now

PostHog recently published an essay titled "How to demo" in its newsletter, and it blew up on Hacker News and GeekNews. The thesis is simple: the ability to build a good product and the ability to demo it well are separate skills, and without the latter, the former might as well not exist.

There is a reason this essay resonated so strongly in 2026. With AI coding agents now ubiquitous, the cost of "building" itself has collapsed. Spinning up a prototype over a weekend with Claude Code or Codex is routine, and the number of projects showing up at internal hackathons and demo days has multiplied. As artifacts become abundant, what becomes scarce is the ability to convince someone in three minutes why any of it matters.

I have lived this myself. I have watched months of internal platform work collapse in an executive review under a single question — "So what actually got better?" — and I have watched a technically unremarkable project land at the center of a quarterly roadmap on the strength of one well-crafted five-minute demo. Demos are not fair. But if those are the rules of the game, learning the rules is the rational move.

This post takes the PostHog thesis as a starting point and treats the demo not as a talent but as an engineerable procedure: structure, script, rehearsal, environment preparation, audience tuning, and failure recovery — all centered on code examples and checklists.

Why Demos Decide Adoption, Investment, and Promotion

Let us start with a cold-eyed look at reality. Demos matter because of three asymmetries.

1. The Information Asymmetry

You have been thinking about this project for weeks or months. Your audience is hearing about it for the first time. Context that is self-evident in your head simply does not exist in theirs. A demo is an act of compression that closes that gap in a few minutes. If the compression fails, the audience remembers their own confusion, not your project.

2. The Time Asymmetry

Decision-makers never have enough time. In a quarterly review, a single project typically gets five to ten minutes. Having six months of work judged in five minutes is absurd — but the fact that you can design those five minutes is also an opportunity.

3. The Memory Asymmetry

People remember scenes, not logic. The sentence "we improved API response time by 40 percent" is forgotten; the ten seconds where a slow screen and a fast screen sit side by side survive long after the meeting ends. Being remembered in a promotion committee as "ah, the person who gave that demo" is worth more than people think.

This is also the core insight of the PostHog essay: a demo is not information transfer, it is a transfer of conviction. If you succeed in transferring your conviction to the audience, adoption and investment follow. If you fail, even great code disappears like an unmerged branch.

The Structure of an S-Tier Demo — 15-Second Hook, Problem, Showtime, Impact

Good demos almost always share the same skeleton. As a four-act structure:

+------------+-----------------+----------------------+-----------------+

| (15 sec) | (30-60 sec) | (2-4 min) | (30 sec) |

+------------+-----------------+----------------------+-----------------+

+------------+-----------------+----------------------+-----------------+

Act 1: The Hook — Show the Result in the First 15 Seconds

The most common mistake is opening with background. Start with "This project began back in Q3 last year, and the architecture at the time..." and within fifteen seconds half the audience is checking Slack.

An S-tier demo leads with the conclusion. It is the same principle as a movie trailer opening with its best shot.

Bad opening: "Today I would like to share our deployment pipeline improvements. First, let me explain the existing structure..."

Good opening: "Until yesterday, a deploy took 40 minutes. I am now going to deploy in 90 seconds, live. Starting the timer."

Act 2: The Problem — Connect to the Audience Pain

Once the hook has their attention, you have 30 to 60 seconds to connect it to a problem the audience owns. The key is to talk about their pain, not your effort. Not the story of paying down tech debt, but the inconveniences that debt inflicted on them: delayed releases, on-call pages, churned customers.

Act 3: Showtime — One Happy Path, Done Perfectly

The golden rule of the live portion: one path, all the way through. Showing one compelling scenario flawlessly for four minutes beats showing ten features for one minute each, by a wide margin. Side features get one sentence: "Beyond this, X and Y also work."

Act 4: Impact — Close with Numbers, End with an Ask

The final 30 seconds do two things. First, the quantitative impact in one sentence: "This change took us from 3 deploys per week to 25." Second, a clear call to action: "To roll this out company-wide next quarter, I need two weeks from one infra engineer. I am asking for that approval." A demo without an ask gets applause and is forgotten.

Live Demo vs. Recorded — Decision Criteria

"Live or recorded?" is the first decision in demo preparation. Here are the criteria in a table.

| Criterion | Live demo | Recorded demo |

| --- | --- | --- |

| Credibility, impact | Highest (proof it is real) | Medium (editing suspected) |

| Failure risk | High | None |

| External dependencies (network, third-party APIs) | Fatal weakness | Irrelevant |

| Improvised demos during QA | Possible | Impossible |

| Timing and pace control | Hard | Perfect |

| Preparation cost | Multiple rehearsals | Editing time |

| Async sharing, reuse | Hard | Excellent |

My practical recommendations:

1. **Default to live**, but mix in recordings when any of the following apply.

2. The path includes **dependencies you cannot control** — external APIs, payments, email delivery → record just that segment.

3. The flow includes **an async operation longer than 3 minutes** (build, training, migration) → start it live, then switch to a pre-run result (the cooking-show "bread we baked earlier" technique).

4. The audience is **external investors or a major customer** and the cost of failure is unrecoverable → recorded main body plus live QA.

5. In every case, **prepare a backup recording**. The difference between "I have a recording for exactly this situation — let us watch it" and the demo simply dying is enormous.

How to Write a Demo Scenario Script

A demo is not improvisation; it is a scripted performance. The key to the script is separating "what you say" from "what you operate." Here is the format I actually use.

Demo script: Deploy Pipeline v2 (6 min total, audience: eng leadership)

[0:00-0:15] Hook

Say: "Until yesterday, deploys took 40 minutes. I will now

deploy in 90 seconds. Starting the timer."

Do: Start stopwatch app. Switch to terminal tab 1.

[0:15-1:00] Problem

Say: "Last quarter our releases slipped by two days on average.

70 percent of the cause was the deploy queue.

You all remember the Friday-afternoon Slack lottery

for deploy slots."

Do: Nothing (no screen switching; hold on face/slide)

[1:00-4:30] Showtime (happy path)

Say: "Assume a bugfix PR just merged."

Do: Run deploy command in terminal -> switch to CI dashboard

Say: "It auto-deploys to canary and watches error rates for

5 minutes. For the demo I shortened the window to 30s."

Do: Zoom into canary traffic graph (200 percent zoom)

Say: "Error rate normal. Auto-rollout to full production."

Do: Refresh production URL -> verify the change

Say: "Check the timer. 87 seconds."

[4:30-5:00] Impact

Say: "In the 2-week pilot: deploys per week went from 3 to 25,

mean rollback time from 22 minutes to 40 seconds."

[5:00-5:30] Ask

Say: "Company-wide rollout needs one infra engineer for

2 weeks. I am asking for approval this sprint."

[Reserve] 3 anticipated questions with one-line answers on a card

Rules for writing the script:

1. **Separate "Say" and "Do".** Talking while operating and botching both is the most common accident. While operating, either stay silent or deliver a memorized line unrelated to the operation.

2. **Time-box every section.** Without per-section timestamps, the showtime sprawls and the impact and ask get cut. Trim the front to protect the most important final minute.

3. **Bake the numbers in.** Not "it got a lot faster" but "from 40 minutes to 87 seconds." Precise numbers evaporate on stage unless they are written in the script.

4. **Memorize the first and last sentences verbatim.** The middle can be delivered from keywords, but if the opening and the close stumble, the whole impression collapses.

Rehearsal — The Rule of Three and the Failure Inventory

As the PostHog essay also stresses, what people who demo well have in common is not talent but rehearsal count. In practice I recommend the rule of three.

1. **Round 1 — Alone, without stopping.** Actually speak and actually operate, start to finish. A mental simulation is not a rehearsal. At this stage you will discover the runtime is 30 to 50 percent over budget. Cut.

2. **Round 2 — In front of one colleague.** Show it to a colleague with zero context and ask only one question: "Where did you get confused?" Do not collect compliments. Collect confusion points.

3. **Round 3 — Real room, real gear.** The actual meeting room (or the actual video tool), the actual laptop, the actual network. Text that was legible on your office monitor but invisible on the projector, and dashboards reachable only over the corporate VPN — these are discovered only at this stage.

While rehearsing, build a **failure inventory**. The format is simple.

Failure inventory: deploy pipeline demo

| Point of failure | Symptom | Plan B |

|------------------------|-----------------------|-------------------------------|

| CI dashboard load | 8s delay on cold load | Pre-open tab, refresh only |

| Canary graph | Could show zero data | Run seed script 10 min before |

| Meeting room wifi | Corp network flaky | Phone tethering pre-connected |

| Production URL | Cache shows old build | Incognito + cache busting |

| Total live failure | Unrecoverable | Backup recording (tab 5) |

The value of this list is not preventing accidents but making sure you **do not panic** when one happens. If plan B exists on paper, recovery takes three seconds.

Preparing the Demo Environment — Solve It with Code

Demo reliability comes from engineering, not willpower. Three field-tested techniques, with code.

1. Data Seeding — Never Demo an Empty Screen

A demo on an empty dashboard — zero users, no graphs — convinces no one. Build a script that seeds demo data reproducibly.

// scripts/seed-demo.ts

// Run once right before the demo: pnpm tsx scripts/seed-demo.ts

const DEMO_ORG = 'acme-demo'

async function seedDemo() {

// Idempotency: delete existing demo data, then recreate

await db.event.deleteMany({ where: { orgId: DEMO_ORG } })

// Generate trending data so the graph tells a story

const events = []

for (let day = 30; day >= 0; day--) {

const base = 120 + (30 - day) * 18 // upward trend

const count = base + Math.floor(Math.random() * 25)

for (let i = 0; i < count; i++) {

events.push({

orgId: DEMO_ORG,

type: 'deploy_completed',

durationSec: 60 + Math.floor(Math.random() * 40),

createdAt: subMinutes(subDays(new Date(), day), i * 3),

})

}

await db.event.createMany({ data: events })

console.log(`Seeded ${events.length} events for ${DEMO_ORG}`)

}

seedDemo()

Three points matter. Idempotency (running it repeatedly yields the same state), trend (the graph should slope upward and tell a story), and realism (names and numbers should look plausible — the moment "test1, test2, asdf" appears on screen, the demo loses class).

2. The Demo-Mode Flag — Remove Uncertainty in Code

The scariest thing in a live demo is an external dependency: payment API timeouts, email delivery lag, nondeterministic LLM responses. A demo-mode flag makes just the risky segments deterministic.

// src/lib/demo-mode.ts

export const isDemoMode = (): boolean =>

process.env.DEMO_MODE === '1'

// src/services/payment.ts

export async function chargeCard(amountCents: number) {

if (isDemoMode()) {

// Instead of calling the real PG, return success after 0.8s

await new Promise((r) => setTimeout(r, 800))

return { status: 'succeeded', id: 'demo_ch_001' }

}

return await realPaymentGateway.charge(amountCents)

}

Three caveats. First, apply demo mode **minimally, only to risky segments**. Mock everything and it is no longer a demo, it is an animation (and the QA session will expose it). Second, do not hide that you are using it. Saying "payments are in sandbox mode" costs you nothing; only a discovered lie costs trust. Third, guard the flag so it never leaks into production.

excerpt from .github/workflows/deploy.yml

- name: Guard against demo mode in production

run: |

if [ "$DEMO_MODE" = "1" ]; then

echo "DEMO_MODE must not be enabled in production"

exit 1

3. Network Plan B

Three checks. Connect phone tethering **before the demo starts** (connecting after the incident burns two minutes); prepare a **local fallback** if the thing you are demoing can run locally; and verify **in advance** that the guest wifi in the meeting room can reach your internal dashboards. The third one breaks surprisingly often.

Tuning per Audience — Same Demo, Different Emphasis

The skeleton stays the same, but the emphasis must change with the audience.

| --- | --- | --- | --- |

| Right length | Under 5 min | 10-15 min | 15-20 min |

The thing to remember in executive demos: they are not buying technology, they are buying **a decision**. Not "how elegant is this tech" but "what improves if I approve, and what do we lose if I do not." Conversely, a hyped marketing tone in front of engineers destroys trust instantly. With engineers, leading with limitations and trade-offs actually increases persuasiveness.

Ten Common Failures and Recovery Lines

Recovery matters more than prevention. Ten failures I see in the field, with lines you can use in the moment.

1. **The app died** → "The good news is I prepared a recording for exactly this. Let us continue with it." (Switch to the backup recording within 5 seconds.)

2. **Loading takes forever** → Never go silent. "While this loads, one thing worth noting..." and deliver a prepared sentence (an impact number). Past ten seconds: "Let me leave this running and show you the next screen first."

3. **Demo data is empty** → "The seed data got reset. Let me show the prepared screenshots, and I will rerun it live after we finish."

4. **Clicked the wrong button** → Show no panic; just navigate back. A long apology doubles the visibility of the mistake. "Let us go back" is enough.

5. **An unexpected error toast appeared** → With an engineering audience, honesty wins: "Oh — a real error. I will file an issue and continue." It actually becomes proof the demo is genuinely live.

6. **A question interrupts mid-showtime** → "Great question. That exact screen comes up in two minutes; I will answer it there." The point is reclaiming control of the flow.

7. **You are told your time was cut in half** → Cut the showtime and jump to impact and ask. This is possible only if your script has a pre-marked "short path."

8. **Screen sharing will not work** → "While I sort out permissions, let me give you the punchline first..." Deliver the hook verbally. Parallelize troubleshooting and presenting.

9. **A challenge to your numbers** ("That 40 percent — measured how?") → "The methodology is in the appendix; I will share the link after this." Burning your remaining time on an improvised defense is the worst outcome. But the appendix must actually exist.

10. **Total blackout (laptop death, etc.)** → Prepare a 60-second no-equipment spoken version in advance. "Since the hardware is not cooperating, here is the core: deploys went from 40 minutes to 90 seconds, and the approval I need is a two-week task." Almost nobody can do this, which is exactly why doing it is so memorable.

Building an Internal Demo Culture — Running Demo Day

To turn an individual skill into a team capability, a recurring demo day works. PostHog and many other companies institutionalized weekly demos for a clear reason: when demoing becomes routine, people develop the habit of slicing work into showable units — which translates directly into small PRs and fast feedback loops.

Example operating rules:

1. **Fixed cadence and length**: every other Friday, 30 minutes. Let it sprawl and it dies.

2. **Hard 5-minute limit per person**: put the timer on screen, publicly. Anything that cannot be shown in 5 minutes is a presentation, not a demo.

3. **No slides, screen only**: the point of demo day is seeing things that move. Allow slides once and everything becomes slides.

4. **Codify the "unfinished is welcome" rule**: write down explicitly that showing work at the embarrassing stage is normal. Without psychological safety, only finished work shows up — and then it is a quarterly report, not a demo day.

5. **Record and archive**: record every demo and pile them into a channel. They get reused as onboarding material for new hires and as evidence in promotion packets.

6. **Mandatory reactions**: require one question or one compliment per demo. If demos keep ending in silence, people stop signing up.

It also helps to define metrics for whether the practice is healthy:

1. **Participation rate**: average number of presentations per demo day, per quarter. A decline means something broke in psychological safety or time budgets.

2. **Unfinished ratio**: the share of presentations that are work in progress. When this converges to zero, your demo day has degenerated into a status report.

3. **Follow-through rate**: collaborations, adoptions, and issue reports that started from a demo. The real ROI of demo day is this number, not the applause.

Finally, I recommend that the very first presenter at demo day always be the leader. One instance of a leader cheerfully showing a half-broken prototype is more powerful than ten pages of "unfinished work is welcome" policy.

Remote Demo Tips

In 2026, half of all demos happen over video calls. Remote-specific tips:

1. **Zoom level at 200 percent**: your screen appears at half size to the audience. Browser at 200 percent zoom; terminal and editor fonts at 18pt or larger. Do not ask "can everyone see this?" — start big from the first second (the moment you ask, three people answer "a bit bigger please" and a minute is gone).

2. **Share a virtual desktop, not a single window**: single-window sharing creates the re-share-on-every-tab-switch accident. Create a dedicated virtual desktop, place only the needed windows on it, and share the whole desktop. Slack and notifications go into do-not-disturb, always.

3. **Speak with your mouse**: you cannot direct eyes remotely, so enlarge the cursor (OS setting) and verbally point before clicking: "this button right here."

4. **Eliminate silent gaps**: five seconds of silence is fine in person; on a call it reads as "did it freeze?" Keep talking through every load.

5. **Hit record at the start**: a remote demo is a free recording asset. A good live demo recording becomes the backup video for your next demo — build that flywheel.

Variations by Stage — Hackathons, Quarterly Reviews, Job Interviews

Even with the same four-act structure, time allocation and emphasis change with the stage. Three representative variations:

Time allocation guide (variations of the 4-act structure)

Hook Problem Showtime Impact/Ask

Hackathon 10 sec 20 sec 2 min 30 sec

Quarterly rev. 15 sec 1 min 3 min 2 min

Job interview 15 sec 30 sec 4 min 1 min (invite questions)

The Hackathon Demo (3 minutes)

Judges watch dozens of demos a day. Their head holds exactly one question: "what is different about this one?" Bet everything on a single differentiator. Listing your tech stack is the worst possible use of time — "we built it with React and FastAPI" is not something a judge remembers. One working moment is the entirety of what gets remembered. And since hackathons have the flakiest networks of any venue, a local fallback and a backup recording are not optional but mandatory.

The Quarterly Review Demo (5-10 minutes)

What makes quarterly reviews special is the link to "last time's promise." Put last quarter's stated goal back on the first slide and show that this demo is the fulfillment of that promise — trust compounds like interest. Double the weight of the impact section and end with next quarter's promise, in measurable form. Executives are buying the signal of "a team whose promise-delivery cycle works" more than the demo itself.

The Portfolio Demo in a Job Interview

If you get the chance to show a side project in an interview, after the walkthrough, **hand the controls to the interviewer**. Surrendering control signals confidence, and a product that survives in the interviewer's own hands speaks louder than any words. Also prepare one failure story — "I originally designed this part as X, then rebuilt it because of problem Y" proves seniority better than a flawless success story.

The Pre-Demo Mental Routine

Whatever the stage, the final five minutes are the same. Say your first sentence out loud three times (a silent mental read-through is half as effective), take a sip of water, and remind yourself: "even if the demo dies, I have a recovery line." The composure of a prepared person is contagious to the audience.

After the Demo — Turning Momentum into Assets

The moment the demo ends is the real beginning. Applause has a shelf life of 48 hours, and within that window momentum must be converted into assets.

1. **A follow-up message within 24 hours**: send the recording link, the three key numbers, and a restatement of the ask (CTA) you made in the demo. This is the act of re-registering "a decision to make" in the decision-maker's inbox.

2. **Turn the question log into an asset**: questions asked during a demo are free market research into what your audience worries about. Organize them into an FAQ document and your anticipated-questions card for the next demo writes itself.

3. **A rejection is data too**: if the ask was declined, ask on the spot — and record — "what would need to be true for us to revisit this?" Distinguishing "not now" from "not ever" determines next quarter's strategy.

Pitfalls and Counterarguments — Against Demo Maximalism

For balance, the opposing case deserves attention.

The criticism that "if only good demoers get rewarded, quiet builders lose" is valid. Demo skill and engineering skill are imperfectly correlated, and the pathology of demo-driven development — flashy demos papering over flimsy foundations — is real. Work that is inherently hard to show (infrastructure, security, refactoring) risks systematic undervaluation in a demo-day culture.

The response runs in two directions. At the organizational level, keep evaluation channels beyond demos alive: design docs, operational metrics, peer feedback. At the individual level, accept the paradox that the harder your work is to show, the more showing skill you need. Before/after latency graphs, a declining trend of on-call pages, a diff of vulnerability scan results — infrastructure work can be turned into scenes too.

The other trap is the **over-optimized demo**. Polish things too smoothly with demo mode and seeding, and the gap with the real product surfaces after adoption, costing you far more trust than you gained. A demo should be the best version of your product — never a version of your product that does not exist.

The Demo Checklist

A checklist for the day before and the minutes before.

By the day before:

1. Script complete (Say/Do separated, time-boxed, first/last sentences memorized)

2. Three rehearsals done (alone → colleague → real environment)

3. Failure inventory and plan B written

4. Backup recording ready, playback position verified

5. Demo data seed script verified

6. Short version (half time) path marked in the script

30 minutes before:

1. Run the seed script, verify screen state

2. Block all notifications (OS do-not-disturb + Slack + mail)

3. Arrange only the needed tabs, in order, on the demo virtual desktop

4. Browser zoom 200 percent, terminal font enlarged

5. Tethering pre-connected, backup recording tab open

6. Glass of water, timer ready

Afterward:

1. Follow up within 24 hours on any question you could not answer

2. Confirm the decision-maker's answer to your ask

3. Archive the recording; register it as the backup for the next demo

Closing

A demo is not a talent; it is a procedure. A 15-second hook, one happy path, close with numbers, end with an ask. Three rehearsals and a failure inventory, a seeding script and a demo-mode flag. Nothing in this post is speech training. All of it is engineering.

In an era where the cost of building has collapsed, the ability to show is a developer's second compiler. If code is the language that conveys intent to machines, the demo is the language that conveys value to people. Lacking either one means being only half a developer.

References

- PostHog Newsletter — How to demo: https://newsletter.posthog.com/p/how-to-demo

- GeekNews discussion — How to demo: https://news.hada.io/topic?id=30265

- Hacker News — PostHog How to demo discussion: https://news.ycombinator.com/

- PostHog Handbook — the public company handbook culture: https://posthog.com/handbook

- Kapwing — demo video production guides: https://www.kapwing.com/resources/

- Stripe Docs — test mode and sandbox design as reference: https://docs.stripe.com/testing

- GitHub Actions official docs — environment variables and guards: https://docs.github.com/en/actions

- Zoom official docs — screen sharing best practices: https://support.zoom.com/hc/en

- date-fns official docs (library used in the seed script example): https://date-fns.org/

- 37signals — Shape Up, slicing work into demoable units: https://basecamp.com/shapeup