How to run an internal-tools demo night that outside engineers actually show up to

The day before our second internal-tools showcase, one presenter's flights were cancelled outright. A few hours before doors, a demo hit a breaking bug. The night still ran on time, because the run-of-show already planned for contigencies. Nobody had to improvise in front of a room, we got a ton of excellent questions from our audience, and people stayed long after the presentations to mingle and discuss AI infra, tooling and emerging patterns.

We've run this event twice. Our first Applied AI Showcase was in San Francisco on May 20, 2026, and our most recent was in New York on July 28, 2026.

An evening like this is won or lost in the run-of-show. The tools are almost beside the point — if the pacing is wrong, good work looks bad.

Five talks, eight to twelve minutes each

The lineup is five talks, each 8-12 minutes.

Eight minutes is also long enough to show a real system and short enough that the program keeps moving. We like to leave room for questions at the end that we answer as a panel, and for unstructured mingling time.

Every talk ends in a live demo

Every talk has to include a live demo. Slides are allowed, but light on text. The rule exists because an internal-tools night has one advantage over a conference talk: the thing being described is running on the presenter's laptop, right now, on real company data.

The rule also teaches presenters a useful pattern. At the SF showcase, one presenter kicked off a live wow app create, cut back to slides while it built, and returned at the end to an app that was live and reachable internally, behind zero trust.

In our NY Showcase, I kicked off some drafts with Blog Bot and then pivoting to explain its architecture and key design decisions while it iterated.

Start the slow thing, talk over it, return to it. The audience learns that the scaffolding really does set up AuthKit, Cloudflare Workers, a SQLite database, Doppler secrets, and a GitHub Action that deploys on merge, or draft an entire article from start to finish in three minutes, because they watched it happen live.

Hold every question to the end

No Q&A after individual talks. One combined Q&A at the end.

This rule keeps the presentations running on a tight clip and ensures the program doesn't get de-railed. You also get better discussions when every presenter is available as a panel and we often respond to and expand upon one anothers' answers.

Sequence the lineup as an argument

The order of talks is an argument, and you should write it like one.

In New York we put Wallaby directly before Atlas on purpose. Wallaby is one very specific agent we invested in: go-to-market intelligence built after embedding with the GTM org, structured enrichment workflows plus a Slack-native agent that triggers them from natural language. Atlas is the generalized platform. In that order, the second talk lands as "and here's how anyone could build that". Reverse them and you get a platform pitch followed by an example.

The general form: put the concrete, specific thing first and the generalization second.

Write the contingency down before you need it

Every demo gets a contingency, written into the run-of-show in advance. It has to be a specific line naming which segment gets dropped and what fills the gap.

Two things went wrong before doors opened in New York: a cancelled flight and a breaking bug in one demo. The written plan already covered the second case and named the fallback, so the decision took a hallway conversation instead of a stage improvisation. Any live system with real moving parts can go red an hour before doors through no fault of the presenter. The plan is what keeps that a logistics note instead of an incident.

A missing presenter is the harder case, because no fallback command replaces a person. The only thing that saves you there is the sequencing rule above: if the lineup is an argument, you know which talk can be pulled without breaking it. Decide that in advance too, on paper, when nobody is stressed.

Staff check-in with people

Check-in is staffed with real humans. It costs two people for half an hour, and it's the only moment where every guest interacts with your company one-to-one.

It's also where you meet the arithmetic of free evening events: in our experience, roughly a fifth to a third of the RSVP list turns into a body in the room. Plan food, chairs, and the badge table against the number who actually walk in, and plan the invite list against the delta.

Record it like it will outlive the room

We hired a video crew for New York and captured both a full recording and a sizzle reel. These keep paying out after the room empties.

The SF recording is the proof. It's still public on the WorkOS channel, uploaded in May 2026, and it's what people watch when they want to know how we actually build. The written recap of that night was drafted during the Q&A itself by BlogBot, one of the tools that had just been demoed on stage, and the New York edition has its own recap. One evening, three durable outputs.

You can watch the full recording of the first Applied AI Showcase in SF below:

You can watch the full recording of the NY Applied AI Showcase below:

What the format is protecting

None of these rules are about the demos. They exist to remove the things that make an outside engineer regret giving you a weeknight: dead air while a build fails, and a Q&A that spends twenty minutes on one person's follow-up.

The content takes care of itself if the tools are real. Our founder Michael Grinich's framing at the first showcase was that showing internal work publicly is partly about hiring, and partly that it feels like a new way of working worth sharing. Both only land if the room is seeing real production systems run live.

If you're running your first one: pick five talks, cap them at twelve minutes, write the contingency line for each, and order them so the last talk answers the first. Everything else is catering. And for a different scale of the same idea, see what 21 five-minute demos looked like at our internal demo night.