Somewhere in your community, right now, someone is building something in their spare time that is either brilliant, terrible, or both. They have been working on it nights and weekends for three months. They have shown it to exactly one person (their partner, who smiled supportively and said "that is really cool, babe" without understanding any of it). They need an audience. Not a big audience. Not an investor audience. Just a room full of people who will look at what they built and give them honest, human feedback.
That is what a demo night is for. It is the open mic of the maker world — a stage for unfinished things, weird experiments, and side projects that may or may not go anywhere. And like any open mic, the quality of the evening depends almost entirely on how you structure it.
The Format That Works (Five Minutes, Hard Stop)
Every demo night that has ever gone sideways went sideways for the same reason: time management. Specifically, the lack of it. Someone gets up to show their project, starts with three minutes of backstory, takes four minutes to set up their development environment, and then spends fifteen minutes demoing features while the audience quietly loses the will to live.
Five minutes. Per presenter. That is your budget. Not five minutes "approximately." Not five minutes "but we can go over if it is really interesting." Five minutes, after which a timer goes off and someone (you, ideally, or a designated timekeeper) politely but firmly says "let us wrap up."
Five minutes is tight. That is the point. Constraints force clarity. If you cannot explain what your project does and show the interesting parts in five minutes, you do not understand your own project well enough yet — and that is actually a useful thing to discover in front of a friendly audience rather than in front of a potential customer.
After each demo, budget two minutes for questions from the audience. Not five. Not "as many as people have." Two minutes. This gives the audience a chance to engage without letting the Q&A become a second demo session. If people have more questions, they can find the presenter afterward — which is actually a better format for deeper conversations anyway.
Handling the Person Who Will Not Stop Talking
There is always one. They are passionate about their project (genuinely, which makes this harder), and they interpret the stage as an invitation to share every design decision, every pivot, every feature they plan to build over the next eighteen months. They are oblivious to the timer, immune to subtle cues, and utterly convinced that the audience shares their level of interest in the technical architecture of their to-do list app.
You need a system, not a confrontation. Here is what works: a visible countdown timer on a screen (not just on your phone). A one-minute warning signal (a gentle chime or a card held up). And a hard stop with a pre-agreed phrase like "Let us give them a round of applause!" followed by actual applause, which is socially impossible to talk over.
Brief the presenters beforehand. In your confirmation email or pre-event message, be explicit: "Each presenter gets five minutes. We will have a timer visible on screen. When time is up, we will wrap you. This is not personal — it is how we keep the evening fair for everyone." When the expectation is set in advance, the hard stop feels professional rather than rude.
Creating the Atmosphere Where Bad Demos Are Celebrated
The most important thing about a demo night — more important than the format, the timing, the venue, or the food — is the vibe. Is this a place where people feel safe showing unfinished, imperfect, possibly embarrassing work? If yes, your demo night will thrive. If no, only polished projects will be presented, which defeats the entire purpose.
Bad demos should be celebrated. Not sarcastically — genuinely. The person who gets up and says "I tried to build a thing and it does not work and I do not know why" is being braver than the person showing off their polished portfolio piece. Make that explicit. Applaud failure. Ask what they learned. Offer to help debug over drinks afterward.
The way you, as organizer, react to the first bad demo of the night sets the tone for every presenter who follows. If you cringe, people notice. If you are enthusiastic and curious ("Oh interesting, what happened when you tried...?"), people notice that too. Your energy is contagious. Use it deliberately.
Voting, Feedback, and the Danger of Both
Should you do audience voting? Maybe. It depends on what you are optimizing for.
Voting adds energy. People love having opinions and clicking buttons. A "people's choice" award at the end gives the evening a narrative arc — a winner, a moment of celebration, a reason to stay until the end. If your goal is entertainment and engagement, voting works.
But voting also introduces a competitive dynamic that can undermine the "safe space for bad demos" thing you worked so hard to create. If there is a winner, there are losers. The person who showed their half-broken prototype now knows they got two votes while the polished app got twenty. That is discouraging, and next time they might not present.
A middle ground: vote on categories that are not about quality. "Most likely to pivot by next month." "Best use of an API nobody else has heard of." "Strongest 'I built this at 2 AM' energy." Keep it light. Keep it funny. Make every project eligible to win something.
For actual useful feedback — the kind that helps presenters improve their projects — skip the public vote entirely. Instead, give attendees index cards. "Write one thing you liked and one suggestion." Hand the cards to the presenter at the end. Private feedback is more honest and more useful than public rankings.
Keeping the Stage Full Month After Month
The perennial demo night challenge: where do the presenters come from? The first event is easy — you personally recruit five friends who are building things. The fifth event is hard, because you have exhausted your immediate network and need fresh blood.
Open the call for presenters two to three weeks before each event. Make it absurdly easy to sign up — a form with three fields: name, project name, one-sentence description. Lower the bar explicitly. "Did you build something? Anything? Show us." Some of your best demos will come from people who almost did not sign up because they thought their project was not good enough.
Invite people from adjacent communities. The UX designer who attends the design meetup but not yours. The data science person from the analytics group. Cross-pollination keeps the project types diverse, which keeps the audience interested. (Nobody wants to watch seven to-do apps in a row, even if they are all architecturally distinct, which they will insist they are.) If you are running a recurring demo night, keeping your regulars engaged depends on this kind of variety.
Demo night is a stage. Keep it well-lit, keep it inclusive, and keep the timer running. If you need a sponsor to cover the pizza, that is a separate problem with a separate solution. Everything else is details.