Your first meetup talk: from the pitch to the last question
A ten-step guide to a first talk at an app meetup: picking a problem, pitching the organizer, building the outline, rehearsing, demos and handling questions.

Autumn is when meetup organizers start filling the winter calendar, and almost all of them have the same problem. There are plenty of people in the room and not enough people willing to stand at the front of it. I spend a lot of evenings at app meetups in Amsterdam and around the country, and the talks I remember are rarely the polished ones. They are the twenty minutes in which someone explains, plainly, a problem they fought with at work and what they did about it.
That is a talk you can give. This guide walks through a first talk at a local iOS, Android, Flutter or design meetup, in ten steps, from choosing a topic to the hour after you sit down again. It assumes you have never done one and would quite like the first time to go well.
Contains affiliate links. As an Amazon Associate I earn from qualifying purchases.
Step 1: pick a problem, not a subject
Subjects are big: accessibility, Kotlin coroutines, App Store Optimization. A first talk on a subject tends to become a tour of the documentation, and the room has already read the documentation. A problem is small and belongs to you. The week your home screen widget stopped updating. How your team moved four hundred strings into a localization file without breaking a release. Why your onboarding lost people on screen three.
Before anything else, write the talk as one sentence: "We had this problem, we tried that, this other thing worked, and here is what I would do differently." If you can't fill in the sentence, the topic isn't ready. If you can, you already have your outline.
A good test is whether a developer at another company would have asked you about it over a drink. If they would, someone in the audience needs it.
Step 2: choose a format and a length
Most groups offer a few shapes. For a first time, shorter is kinder, to you and to the room.
| Format | Length | A good first choice if | Main risk |
|---|---|---|---|
| Lightning talk | 5 minutes | You have one tip, one tool or one lesson | Squeezing a full talk into five minutes |
| Ignite-style | 20 slides, 15 seconds each | You like rehearsing to a fixed rhythm | Slides moving on before you are ready |
| Short talk | 15 to 20 minutes plus questions | You have a story with a before and an after | Running long |
| Live demo | 10 to 15 minutes | The tool itself is the story | Wi-Fi, cables and notifications |
| Full talk | 25 to 30 minutes | You have done a lightning talk already | Losing the room in the middle |
The Ignite format, first run in Seattle in 2006, makes the slides advance on their own every 15 seconds, so the whole talk lasts exactly five minutes. Some first-time speakers find that terrifying. Others find it a relief, because the format does the pacing for them. Either way, a five-minute slot is a fine way to learn how a room feels before you commit to twenty.
Step 3: pitch it to the organizer
Most groups have a form, a channel in their Slack or Discord, or an organizer who answers messages. Send a working title, three sentences on what people will take home, the format and length you want, the level (beginner, intermediate, advanced) and the fact that it is your first talk. That last line helps rather than hurts. Organizers of a monthly evening are always short of new speakers, and many will offer a run-through or feedback on a draft.
Our guide to planning a meetup program explains how organizers think about calls for talks, mixing levels and what to do when a speaker drops out. It is worth reading from the other side of the table, because it tells you what makes a proposal easy to say yes to.
Ask the practical questions now, not on the night. How long is the slot, exactly? How many people usually come? Is there a projector, and does it take HDMI or USB-C? Is there a microphone? Will the talk be recorded? Each answer changes the slides.
Step 4: build the outline before the slides
Open a text file, not a slide tool. For a twenty-minute talk, a structure like this works for most problem stories:
- The situation, about two minutes: the app, the team, the constraint. Enough context to care, no company history.
- The problem, about three minutes, with one concrete artifact: a crash log line, a screenshot of a funnel, a one-star review.
- What you tried first, about four minutes, including what didn't work. Audiences trust a speaker who shows a dead end.
- What worked, about six minutes: the fix, with the one snippet or screen that matters.
- What you would do differently, about three minutes.
- One takeaway and where to read more, one minute.
That leaves a little room for questions inside a twenty-five-minute slot. If the outline doesn't fit on one screen of the text file, the talk is too long.
Step 5: make slides for the back row
Meetup projectors are often dim, and the lights in an office canteen rarely switch off completely. Design for that.
- One idea per slide, in large type.
- Code at no more than about ten lines, in a big font, with the line that matters highlighted.
- Strong contrast between text and background, and no meaning carried by color alone.
- Phone screenshots cropped to the part you are talking about, then enlarged.
- Slide numbers, so people can ask about "slide 14" afterward.
- A PDF export on a USB stick and on your phone, in case your laptop and the projector refuse to talk.
Step 6: plan the demo, and a recording of it
A live demo is the most memorable part of many meetup talks and the part most likely to go wrong. Reduce the odds. On a Mac, QuickTime Player can show a cabled iPhone's screen through a new movie recording, with the phone picked as the camera. Android Studio can mirror a connected Android device in its Running Devices window, as long as USB or wireless debugging is on. Either way, switch on a focus or do-not-disturb mode first, so a message from your family doesn't appear in front of forty strangers.
If you would rather point a camera at a real phone on the table, an adjustable phone stand keeps it steady and upright while you tap. That pick is chosen from its specifications and published reviews; we haven't tried it on a stage ourselves. And whatever you use, record a short video of the demo working the day before. If the Wi-Fi fails, you play the video and keep talking.
Step 7: rehearse out loud, three times
The first rehearsal is alone, standing up, with a timer. It will run long, almost everyone's does, so cut until you finish a few minutes under the slot. Nerves and questions add time on the night.
The second rehearsal is for one colleague or friend. Afterward, ask them a single question: what was the one thing to remember? If their answer isn't the takeaway you wrote in step 4, rework the middle of the talk, not the ending.
The third rehearsal is at full speed, with the clicker or keyboard you will use and the demo running. Don't memorize a script. Memorize your first two sentences and the transitions between sections. Everything else can be said slightly differently each time without anyone noticing.
Step 8: on the night
Arrive early. The rest is a short list:
- Test your laptop, adapter and slides on the actual projector before people arrive.
- Agree a signal with the organizer at five minutes and at one minute left, or find out where the clock is.
- Silence the phone and laptop, and close every chat app.
- Keep water within reach.
- Repeat each question from the floor into the microphone before you answer it.
- Finish on time, even if it means skipping a slide.
That last point matters more than it looks. The next speaker, the pizza and the train timetable are all waiting on you, and a talk that ends on time feels better to the audience than one that ends complete.
Step 9: the questions and the drinks
Most questions are friendly. The one first-time speakers dread is rarely hostile; it is usually a long comment from someone who knows a related area well. Thank them, find the question inside it, and answer briefly. If they clearly know more than you, say so and suggest you talk afterward. "I don't know, but I can find out" is a complete answer, and so is "we didn't try that".
At Dutch meetups, questions can be blunter than visitors expect. As I wrote in our feature on the Dutch app scene, the directness is mostly a sign that people were listening, and most speakers take it in that spirit. The real reward comes at the drinks afterward, when people who were too shy to ask in public come over with the question they actually had. Keep a note on your phone of who asked what, because some of those conversations become your next talk.
Step 10: after the talk
Send your slides to the organizer within a day or two, with links to anything you mentioned. Ask them for one piece of honest feedback. Then write the talk up as a short blog post while it is fresh. The written version reaches people who weren't there, and it is the version future organizers will read when they look you up.
A talk that worked at a meetup is also the seed of a conference proposal. Speaking is one of the established ways into larger events without paying for a full pass, and our guide to conference passes for less explains how speaker and workshop passes usually work. Many good conference talks started as twenty minutes in an office canteen.
Tonight, write the one sentence from step 1. If it still sounds true after a week, send it to an organizer with the line "this would be my first talk". That is the hardest message in this whole process, and it takes about two minutes.
Keep reading

A mobile developer's desk: hubs, cables, chargers and stands
What a mobile developer's desk needs: USB-C hubs and specs that matter, data versus charging cables, multi-port chargers, phone stands and a second screen.

The Dutch app scene: communities, meetups and how it grew
How the Netherlands built a friendly app community, from CocoaHeadsNL and Appsterdam to platform meetups beyond Amsterdam, and where a newcomer should start.

From mobile developer to engineering manager: what changes
A freelance iOS developer looks back on two years as a mobile team lead: the calendar, one-to-ones, hiring, saying no, and why going back to code is fine.