24 tips for giving S-tier demos
An engineer's guide on how to demo well
A good demo can be the difference between a project shipping or shutting down, and a startup getting funded or going nowhere.
Yet most developers don’t invest in learning how to demo well – probably because we enjoy building things more than presenting them.
I watched 50+ hackathon demos back to back at our offsite last week and, after that many in a row, some patterns became super obvious.
Here's a practical list of what set the S-tier demos apart from the rest.
The basic structure
1. Pick one main point you want people to remember and make everything else in your demo revolve around it. Typically, this should be the problem you’re solving and how you’re solving it.
2. Get to your main point as soon as possible. No one needs the whole story behind the idea – if you need context, keep it 1-2 sentences max.
3. Treat the demo like a pitch, not a product walkthrough. The goal isn’t to just show off the cool thing you made, it’s to get people excited about it.
4. End with something immediately actionable. It can be as literal as a QR code, or simply calling for contributors and inviting audience questions.
One team during our offsite hackathon created a system that lets you interact with PostHog over any messaging app, so they put up a phone number in their last slide (which I texted right away):
The MCP Analytics team even announced that their project was already rolled out to 25% of PostHog users. Shipping before you even demo adds a huge "wow" factor, especially if you can show real user data flowing.
Storytelling tactics
5. Lead with a shared pain point that everyone in the audience understands.
Two of our designers built a web app that automatically tags and indexes illustrations. They opened their demo by asking who has had trouble finding a specific hedgehog in their chaotic lovely “Hoggies” Figma file. Everyone raised their hand.
6. Borrow a familiar concept to explain a new one. For example, one hackathon team explored building our own take on Claude Cowork inside PostHog Code, so they creatively named their project PostHog Work.
7. Create a separate demo app, especially if you’re showing off a dev tool.
Dev tools are easier to grasp once people see them applied. For example, one team created a tool to instruct and deploy agents that manually test your UI. The idea only clicked once they showed it on a separate demo app called OnlyHogs (it’s fake, I checked):
8. Use “you” framing to put the audience in the right perspective. Instead of saying “we built an app to manage support tickets”, one team asked the audience to “imagine you’re on-call and you’re trying to resolve six incidents at once.”
9. Demo against the alternative. Show the painful 6-step current workflow side-by-side with your 1-step version. Comparisons create stakes; without them, the audience has no reference for whether what you built is actually good.
10. Save how it works for later. Like how magicians never reveal their tricks, you shouldn’t tell people how you built it (at least, not up front). Sharing a link to a video, or blog post, where you explain this can make a good ending CTA for your demo.
Setup and delivery
11. Channel your inner Steve Ballmer. A great demo is often just a good one from someone with a lot of energy.
12. Don’t apologize. “Sorry, it’s still kind of rough,” trains the audience to lower expectations before you’ve shown anything. Just start.
13. Make it obvious when you’re done. This prevents that awkward moment when people aren’t sure if it’s time to clap. End with a closing sentence, descending intonation, or celebratory visual:
14. Do everything in your power to please the demo gods. We even have a demo setup checklist just for this:
[ ] Use a demo project, not a live account with customer data
[ ] Disable notifications on your laptop
[ ] Silence your phone
[ ] Bookmark your demo URL — don't type it live
[ ] Know what happens if WiFi dies (screenshots as backup)
[ ] Zoom your browser to 125–150% so the back row can read it
[ ] Test the projector before anyone arrives15. Use real data wherever possible. Obviously fake data just looks lame.
When the HogNet team demoed their hackathon-in-a-box rental service concept, they created a website with pricing and shipping logistics. This felt way more realistic than if they had used lorem ipsum:
16. Pre-load and cache as much as you can (without taking away from the demo, of course). It’s like how TV chefs prepare their ingredients in advance to make every second on air interesting.
Common places where you can eliminate dead time include agent responses, long queries, and slow builds.
17. Practice out loud at least once. It helps you build confidence in what you’re saying, so it comes out naturally.
18. Don’t let perfectionism stop you from demoing. Everyone presents at our hackathons, no matter what shape their project was in. Demos are for in-progress work anyways.
Make it fun
19. Avoid showing plain old code. Even if your project doesn’t have a UI, there’s simply no excuse for skipping visuals anymore. You can generate an architecture diagram in seconds:
20. Don’t just show plain old slides, either. Active demos always win. Anyone can talk about a cool idea; the point of a demo is to build it and show it.
21. Default screen recording tools suck. There are plenty of apps like Screen Studio that zoom in and add animations so it’s easier to see what’s going on:
22. Your visuals don’t need to be beautiful. They just need to highlight what’s important. This demo had simple graphics, but each callout provided useful information:
23. Audio is underrated. One team generated a sea shanty voiceover, while another project that does quick calls for AI-powered user research made their demo fully audio-only.
24. Do more weird. No one asked for clips of Dylan sipping piña coladas in the background, but the PostHog Code mobile app team did it anyway. It’s also the demo I remember most. 🍹
Words by Jina Yoon, who had to overcome her fear of public speaking without these tips.
💡 More memorable content
From 270GB RAM to 5GB: Moving local flag evaluation from Django to Rust – Patricio Tarantino
Being AI-native matters more than experience – Fraser Hopper
A guide to growth metrics for startups that don’t fit in – Mine Kansu
How to grow your AEO function (without losing your mind) – Natalia Amorim
The do’s and don’ts of minimum viable product marketing – Joe Martin
Stop adding AI between you and your customers – Abigail Richardson
Posthog write ups are GOAT! Love this
Nice writeup! Thanks!